[OpenSIPS-Users] Rewriting Contact Header -- Should I or Shouldn't I?
Peter Kust
peter.kust at businessuites.com
Sat Mar 29 17:17:24 CET 2014
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
More information about the Users
mailing list