[OpenSIPS-Users] Rewriting Contact Header -- Should I or Shouldn't I?
Peter Kust
peter.kust at businessuites.com
Sat Mar 29 18:46:43 CET 2014
Record-Route: <sip:*.*.*.200;lr>
I believe the answer is yes. The above header field is in the OK message.
Cordially,
Peter Nayland Kust
Director of Technologies
BusinesSuites
24624 Interstate 45 North, Suite 200
Houston, TX 77070
peter.kust at businessuites.com
-----Original Message-----
From: Stefano Pisani [mailto:stefano.pisani at omnianet.it]
Sent: Saturday, March 29, 2014 12:23 PM
To: OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] Rewriting Contact Header -- Should I or Shouldn't I?
Is the request route header present in OK message?
Il 29/03/2014 18.13, Peter Kust ha scritto:
> Is the Contact header in the OK message correct? That is the question of the moment.
>
> When the call gets answered, (after the 180 "RINGING" messages), the Asterisk server sends an OK message to the proxy with a contact header containing the IP address of the Asterisk server in the Contact URI. The Proxy then sends that OK message onto the UAC with the same contact header (i.e., with the IP Address of the Asterisk server in the Contact URI). The UAC then sends the ACK directly to the Asterisk server and bypasses the proxy. As a result, the Asterisk server sends the BYE message directly to the UAC and not the proxy.
>
> This is the Contact header in the OK message the proxy sends to the UAC:
>
> Contact: <sip:********33@*.*.*.102>
>
> *.*.*.102 is the IP address of my Asterisk server. My Proxy server is at *.*.*.200.
>
> Soooo......should the Contact header in the OK message the proxy sends
> to the UAC have the IP address of the proxy or the original IP address
> of the Asterisk server? Is the contact header correct as is, or
> should it read
>
> Contact: <sip:********33@*.*.*.200>
>
> That is where I am getting stumped. That, and what the best/safest and most stable method is for altering that header, if necessary.
>
> Cordially,
>
> Peter Nayland Kust
> Director of Technologies
> BusinesSuites
> 24624 Interstate 45 North, Suite 200
> Houston, TX 77070
> peter.kust at businessuites.com
> -----Original Message-----
> From: Stefano Pisani [mailto:stefano.pisani at omnianet.it]
> Sent: Saturday, March 29, 2014 11:23 AM
> To: users at lists.opensips.org
> Subject: Re: [OpenSIPS-Users] Rewriting Contact Header -- Should I or Shouldn't I?
>
> BYE was never received.
> Check the Contact header in OK message. Is it right?
> Check also the request route. Are they present? Probably NOT because BYE go to The UAC and not to the PROXY.
>
> Cheers,
> s
>
> Il 29/03/2014 17.17, Peter Kust ha scritto:
>> Also, this is how the SIP messaging is proceeding, starting with the
>> INVITE from the GenBand eSBC
>>
>> **.***.***.110 INVITE SDP (g711U telephone-event)
>> (5060) ------------------> (5060) **.***.***.200
>> **.***.***.110 100 Giving a try
>> (5060) <------------------ (5060) **.***.***.200
>> **.***.***.200 INVITE SDP (g711U telephone-event)
>> (5060) ------------------> (5060) **.***.***.102
>> **.***.***.200 100 Trying
>> (5060) <------------------ (5060) **.***.***.102
>> **.***.***.200 180 Ringing
>> (5060) <------------------ (5060) **.***.***.102
>> **.***.***.110 180 Ringing
>> (5060) <------------------ (5060) **.***.***.200
>> **.***.***.200 180 Ringing
>> (5060) <------------------ (5060) **.***.***.102
>> **.***.***.110 180 Ringing
>> (5060) <------------------ (5060) **.***.***.200
>> **.***.***.200 200 OK SDP (g711U telephone-event)
>> (5060) <------------------ (5060) **.***.***.102
>> **.***.***.110 200 OK SDP (g711U telephone-event)
>> (5060) <------------------ (5060) **.***.***.200
>> **.***.***.110 ACK
>> (5060) ------------------------------------------------------------------------> (5060) **.***.***.102
>> **.***.***.110 BYE
>> (5060) ------------------------------------------------------------------------- (5060) **.***.***.102
>> **.***.***.110 BYE
>> (5060) ------------------------------------------------------------------------- (5060) **.***.***.102
>> **.***.***.110 BYE
>> (5060) ------------------------------------------------------------------------- (5060) **.***.***.102
>> **.***.***.110 BYE
>> (5060) ------------------------------------------------------------------------- (5060) **.***.***.102
>> **.***.***.110 BYE
>> (5060) ------------------------------------------------------------------------- (5060) **.***.***.102
>> **.***.***.110 BYE
>> (5060) ------------------------------------------------------------------------- (5060) **.***.***.102
>> **.***.***.110 BYE
>> (5060) ------------------------------------------------------------------------- (5060) **.***.***.102
>> **.***.***.110 BYE
>> (5060) ------------------------------------------------------------------------- (5060) **.***.***.102
>> **.***.***.110 481 Call leg/transaction does not exist
>> (5060) ------------------------------------------------------------------------- (5060) **.***.***.102
>>
>> Cordially,
>>
>> Peter Nayland Kust
>> Director of Technologies
>> BusinesSuites
>> 24624 Interstate 45 North, Suite 200
>> Houston, TX 77386
>> peter.kust at businessuites.com
>>
>> From: Peter Kust
>> Sent: Saturday, March 29, 2014 10:38 AM
>> To: 'users at lists.opensips.org'
>> Subject: Rewriting Contact Header -- Should I or Shouldn't I?
>>
>> I am currently testing an OpenSIPS/Asterisk combination with a GenBand eSBC (Quantix QFlex).
>>
>> My basic architecture looks like this
>>
>> Phone (Cisco SPA525G2) → OpenSIPS proxy → Asterisk Media Server
>> Asterisk Media Server → OpenSIPS proxy → GenBand QFlex eSBC (→PSTN)
>>
>> The GenBand is handling both the SIP and RTP protocols, which means the Asterisk Media Server is sending the RTP stream direct to the GenBand.
>>
>> A problem arises on inbound calls (from PSTN through GenBand to OpenSIPS/Asterisk). During the call setup the GenBand sends a SIP ACK message directly to my Asterisk server, which seems to be causing the Asterisk server to send the BYE message at the end of the call directly to the GenBand instead of via the OpenSIPS proxy. The result is that the external call end point (i.e., my cell phone), never gets a BYE message and that call leg stays open.
>>
>> In the OK message from the proxy to the GenBand, the Contact header contains the IP address of my Asterisk server, and not the proxy. I am being told this is what prompts the GenBand to send to the Asterisk server and not the proxy.
>>
>> >From a packet capture I have run on the offending call scenario, the OK message in question looks like this:
>> Session Initiation Protocol (200)
>> Status-Line: SIP/2.0 200 OK
>> Status-Code: 200
>> [Resent Packet: False]
>> [Request Frame: 9]
>> [Response Time (ms): 4049]
>> Message Header
>> Via: SIP/2.0/UDP *.*.*.110:5060;received=*.*.*.110;branch=z9hG4bK-d8754z-HSTATXOSEB0050004f58cb4f4b0f5-1---d8754z-;rport=5060
>> Transport: UDP
>> Sent-by Address: *.*.*.110
>> Sent-by port: 5060
>> Received: *.*.*.110
>> Branch: z9hG4bK-d8754z-HSTATXOSEB0050004f58cb4f4b0f5-1---d8754z-
>> RPort: 5060
>> Record-Route: <sip:*.*.*.200;lr>
>> Record-Route URI: sip:*.*.*.200;lr
>> Record-Route Host Part: *.*.*.200
>> Record-Route URI parameter: lr
>> From: "**** ****"<sip:********79@*.*.*.110:5060>;tag=HSTATXOSEB0050004f58cb4f4b0f6
>> SIP Display info: "**** ****"
>> SIP from address: sip:********79@*.*.*.110:5060
>> SIP from address User Part: ********79
>> SIP from address Host Part: *.*.*.110
>> SIP from address Host Port: 5060
>> SIP from tag: HSTATXOSEB0050004f58cb4f4b0f6
>> To: <sip:********33@*.*.*.200:5060>;tag=as4f58e1e1
>> SIP to address: sip:********33@*.*.*.200:5060
>> SIP to address User Part: ********33
>> SIP to address Host Part: *.*.*.200
>> SIP to address Host Port: 5060
>> SIP to tag: as4f58e1e1
>> Call-ID: 6654c342.c8fafa0a.5333822b.bf5
>> CSeq: 1 INVITE
>> Sequence Number: 1
>> Method: INVITE
>> Server: Asterisk PBX
>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
>> Supported: replaces, timer
>> Session-Expires: 1800;refresher=uac
>> Contact: <sip:********33@*.*.*.102>
>> Contact URI: sip:********33@*.*.*.102
>> Contact URI User Part: ********33
>> Contact URI Host Part: *.*.*.102
>> Content-Type: application/sdp
>> Content-Length: 240
>> Message Body
>> Session Description Protocol
>> Session Description Protocol Version (v): 0
>> Owner/Creator, Session Id (o): root 1240385050 1240385050 IN IP4 *.*.*.102
>> Owner Username: root
>> Session ID: 1240385050
>> Session Version: 1240385050
>> Owner Network Type: IN
>> Owner Address Type: IP4
>> Owner Address: *.*.*.102
>> Session Name (s): Asterisk PBX
>> Connection Information (c): IN IP4 *.*.*.102
>> Connection Network Type: IN
>> Connection Address Type: IP4
>> Connection Address: *.*.*.102
>> Time Description, active time (t): 0 0
>> Session Start Time: 0
>> Session Stop Time: 0
>> Media Description, name and address (m): audio 7610 RTP/AVP 0 101
>> Media Type: audio
>> Media Port: 7610
>> Media Protocol: RTP/AVP
>> Media Format: ITU-T G.711 PCMU
>> Media Format: DynamicRTP-Type-101
>> Media Attribute (a): rtpmap:0 PCMU/8000
>> Media Attribute Fieldname: rtpmap
>> Media Format: 0
>> MIME Type: PCMU
>> Sample Rate: 8000
>> Media Attribute (a): rtpmap:101 telephone-event/8000
>> Media Attribute Fieldname: rtpmap
>> Media Format: 101
>> MIME Type: telephone-event
>> Sample Rate: 8000
>> Media Attribute (a): fmtp:101 0-16
>> Media Attribute Fieldname: fmtp
>> Media Format: 101 [telephone-event]
>> Media format specific parameters: 0-16
>> Media Attribute (a): ptime:20
>> Media Attribute Fieldname: ptime
>> Media Attribute Value: 20
>> Media Attribute (a): sendrecv
>>
>> And the ACK message that goes back to the Asterisk server and not the proxy looks like this:
>>
>> Session Initiation Protocol (ACK)
>> Request-Line: ACK sip:********33@*.*.*102 SIP/2.0
>> Method: ACK
>> Request-URI: sip:********33@*.*.*102
>> Request-URI User Part: ********33
>> Request-URI Host Part: *.*.*102
>> [Resent Packet: False]
>> Message Header
>> Via: SIP/2.0/UDP *.*.*110:5060;branch=z9hG4bK-d8754z-HSTATXOSEB0050004f58cb533a2c8-1---d8754z-;rport
>> Transport: UDP
>> Sent-by Address: *.*.*110
>> Sent-by port: 5060
>> Branch: z9hG4bK-d8754z-HSTATXOSEB0050004f58cb533a2c8-1---d8754z-
>> RPort: rport
>> Max-Forwards: 70
>> To: <sip:********33@*.*.*200:5060>;tag=as4f58e1e1
>> SIP to address: sip:********33@*.*.*200:5060
>> SIP to address User Part: ********33
>> SIP to address Host Part: *.*.*200
>> SIP to address Host Port: 5060
>> SIP to tag: as4f58e1e1
>> From: "**** ****"<sip:********79@*.*.*110:5060>;tag=HSTATXOSEB0050004f58cb4f4b0f6
>> SIP Display info: "**** ****"
>> SIP from address: sip:********79@*.*.*110:5060
>> SIP from address User Part: ********79
>> SIP from address Host Part: *.*.*110
>> SIP from address Host Port: 5060
>> SIP from tag: HSTATXOSEB0050004f58cb4f4b0f6
>> Call-ID: 6654c342.c8fafa0a.5333822b.bf5
>> CSeq: 1 ACK
>> Sequence Number: 1
>> Method: ACK
>> Content-Length: 0
>>
>> I am being told that the Contact header in the OK message should have the IP address of the proxy and not the Asterisk server. I’m looking at the RFC document, RFC3261, attempting to understand the “rules of the road” here, but am getting confused on the requirements of the Contact Header.
>>
>> Is what I am being told correct? And, if so, what would be the cleanest way to go about correcting that particular header?
>>
>> Cordially,
>>
>> Peter Nayland Kust
>> Director of Technologies
>> BusinesSuites
>> 24624 Interstate 45 North, Suite 200
>> Houston, TX 77386
>> peter.kust at businessuites.com
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
More information about the Users
mailing list