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
[email protected]
-----Original Message-----
From: Stefano Pisani [mailto:[email protected]]
Sent: Saturday, March 29, 2014 11:23 AM
To: [email protected]
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
[email protected]
From: Peter Kust
Sent: Saturday, March 29, 2014 10:38 AM
To: '[email protected]'
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
[email protected]
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
