[OpenSIPS-Users] Rewriting Contact Header -- Should I or Shouldn't I?
Peter Kust
peter.kust at businessuites.com
Sat Mar 29 19:21:21 CET 2014
This is the full OK message that the proxy is sending to the UAC.
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
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 1:01 PM
To: OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] Rewriting Contact Header -- Should I or Shouldn't I?
There are more than one Record-Route.
There is one record with proxy ip? Where you read the messages? on the uac interface?
The message changes according to the point where it is. Proxy shoud add its own record route header.
Il 29/03/2014 18.46, Peter Kust ha scritto:
> 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
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
More information about the Users
mailing list