Hi, I have a SER + Mediaproxy. I have not any problem the call between SIP clients (behind or not the NATs) but when I try to call to PSTN (via cisco) I only have RTP traffic from SIP client to PSTN.
Summarizing, the path of rtp traffic would have to be from:
up: SIP Client ----> SER ---> GW-PSTN down: SIP Client <---- SER <--- GW-PSTN
but, really is:
up: SIP Client ----> SER ---> GW-PSTN down: SIP Client <------------- GW-PSTN
I use the command:
rewritehostport("212.xxx.xxx.xxx:5060");
when I match a geographic number.
The complete scheme is:
SIP Client ---- NAT --------- SER+Mediaproxy -------- SIP Server --- GWPSTN
Some idea?
Thanks,
-- Alberto
I have examine the packet INVITE and have seen the next:
AA.AA.AA.AA = public IP address of SER/Mediaproxy Server. BB.BB.BB.BB = public IP address of endpoint (the endopoint is behind nat) CC.CC.CC.CC = public IP address of SIP SERVER(carrier)
When the SER follows the INVITE message, rewrites the field Contact and fill it with the public ip address of sip client. Can this to be my problem?
In this same message into SDP, in Contact information, the SER change this field BUT write the ip address two times. Can this a bug?
Thank at all, -- Alberto
---------------- INVITE from endpoint to SER: Session Initiation Protocol
Request-Line: INVITE sip:932215863@AA.AA.AA.AA SIP/2.0
Method: INVITE
Resent Packet: False
Message Header
Via: SIP/2.0/UDP 192.168.100.55:5060;branch=z9hG4bK-63bf38d4;rport
From: sip:1000@AA.AA.AA.AA;tag=c1342f3464087414o0
Call-ID: d7eca5b4-6a866f94@192.168.100.55
CSeq: 102 INVITE
Max-Forwards: 70
Contact: sip:1000@192.168.100.55:5060
Expires: 240
User-Agent: Linksys/PAP2-2.0.12(LS)
Content-Length: 428
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER
Supported: x-sipura
Content-Type: application/sdp
Message body
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): - 6735673 6735673 IN IP4 192.168.100.55
Owner Username: -
Session ID: 6735673
Session Version: 6735673
Owner Network Type: IN
Owner Address Type: IP4
Owner Address: 192.168.100.55
Session Name (s): -
Connection Information (c): IN IP4 192.168.100.55
Connection Network Type: IN
Connection Address Type: IP4
Connection Address: 192.168.100.55
........................
INVITE from SER to SIP SERVER(CARRIER):
Session Initiation Protocol
Request-Line: INVITE sip:932215863@CC.CC.CC.CC:5060 SIP/2.0
Method: INVITE
Resent Packet: False
Message Header
Record-Route: sip:932215863@AA.AA.AA.AA:5060;nat=yes;ftag=c1342f3464087414o0;lr=on
Via: SIP/2.0/UDP AA.AA.AA.AA;branch=z9hG4bKa01c.50c2aac6.0
Via: SIP/2.0/UDP 192.168.100.55:5060;received=BB.BB.BB.BB;branch=z9hG4bK-63bf38d4;rport=60413
From: sip:1000@AA.AA.AA.AA;tag=c1342f3464087414o0
Call-ID: d7eca5b4-6a866f94@192.168.100.55
CSeq: 102 INVITE
Max-Forwards: 16
Contact: sip:1000@BB.BB.BB.BB:60413
Expires: 240
User-Agent: Linksys/PAP2-2.0.12(LS)
Content-Length: 445
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER
Supported: x-sipura
Content-Type: application/sdp
Message body
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): - 6735673 6735673 IN IP4 192.168.100.55
Owner Username: -
Session ID: 6735673
Session Version: 6735673
Owner Network Type: IN
Owner Address Type: IP4
Owner Address: 192.168.100.55
Session Name (s): -
Connection Information (c): IN IP4 AA.AA.AA.AAAA.AA.AA.AA
Connection Network Type: IN
Connection Address Type: IP4
Connection Address: AA.AA.AA.AAAA.AA.AA.AA <---------- BUG????????
----- Original Message ----- From: Alberto To: serusers@lists.iptel.org Sent: Thursday, September 22, 2005 10:55 AM Subject: [Serusers] One path of RTP traffic
Hi, I have a SER + Mediaproxy. I have not any problem the call between SIP clients (behind or not the NATs) but when I try to call to PSTN (via cisco) I only have RTP traffic from SIP client to PSTN.
Summarizing, the path of rtp traffic would have to be from:
up: SIP Client ----> SER ---> GW-PSTN down: SIP Client <---- SER <--- GW-PSTN
but, really is:
up: SIP Client ----> SER ---> GW-PSTN down: SIP Client <------------- GW-PSTN
I use the command:
rewritehostport("212.xxx.xxx.xxx:5060");
when I match a geographic number.
The complete scheme is:
SIP Client ---- NAT --------- SER+Mediaproxy -------- SIP Server --- GWPSTN
Some idea?
Thanks,
-- Alberto
------------------------------------------------------------------------------
_______________________________________________ Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
You probably call fix_nated_sdp() twice in your config. g-)
---- Original Message ---- From: Alberto To: Alberto ; serusers@lists.iptel.org Sent: Thursday, September 22, 2005 01:09 PM Subject: Re: [Serusers] One path of RTP traffic (possible bug?????)
I have examine the packet INVITE and have seen the next:
AA.AA.AA.AA = public IP address of SER/Mediaproxy Server. BB.BB.BB.BB = public IP address of endpoint (the endopoint is behind nat) CC.CC.CC.CC = public IP address of SIP SERVER(carrier)
When the SER follows the INVITE message, rewrites the field Contact and fill it with the public ip address of sip client. Can this to be my problem?
In this same message into SDP, in Contact information, the SER change this field BUT write the ip address two times. Can this a bug?
Thank at all,
Alberto
INVITE from endpoint to SER: Session Initiation Protocol Request-Line: INVITE sip:932215863@AA.AA.AA.AA SIP/2.0 Method: INVITE Resent Packet: False Message Header Via: SIP/2.0/UDP 192.168.100.55:5060;branch=z9hG4bK-63bf38d4;rport From: sip:1000@AA.AA.AA.AA;tag=c1342f3464087414o0 To: sip:932215863@AA.AA.AA.AA Call-ID: d7eca5b4-6a866f94@192.168.100.55 CSeq: 102 INVITE Max-Forwards: 70 Contact: sip:1000@192.168.100.55:5060 Expires: 240 User-Agent: Linksys/PAP2-2.0.12(LS) Content-Length: 428 Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER Supported: x-sipura Content-Type: application/sdp Message body Session Description Protocol Session Description Protocol Version (v): 0 Owner/Creator, Session Id (o): - 6735673 6735673 IN IP4 192.168.100.55 Owner Username: - Session ID: 6735673 Session Version: 6735673 Owner Network Type: IN Owner Address Type: IP4 Owner Address: 192.168.100.55 Session Name (s): - Connection Information (c): IN IP4 192.168.100.55 Connection Network Type: IN Connection Address Type: IP4 Connection Address: 192.168.100.55 ........................
INVITE from SER to SIP SERVER(CARRIER): Session Initiation Protocol Request-Line: INVITE sip:932215863@CC.CC.CC.CC:5060 SIP/2.0 Method: INVITE Resent Packet: False Message Header Record-Route: sip:932215863@AA.AA.AA.AA:5060;nat=yes;ftag=c1342f3464087414o0;lr=on Via: SIP/2.0/UDP AA.AA.AA.AA;branch=z9hG4bKa01c.50c2aac6.0 Via: SIP/2.0/UDP 192.168.100.55:5060;received=BB.BB.BB.BB;branch=z9hG4bK-63bf38d4;rport=60413 From: sip:1000@AA.AA.AA.AA;tag=c1342f3464087414o0 To: sip:932215863@AA.AA.AA.AA Call-ID: d7eca5b4-6a866f94@192.168.100.55 CSeq: 102 INVITE Max-Forwards: 16 Contact: sip:1000@BB.BB.BB.BB:60413 Expires: 240 User-Agent: Linksys/PAP2-2.0.12(LS) Content-Length: 445 Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER Supported: x-sipura Content-Type: application/sdp Message body Session Description Protocol Session Description Protocol Version (v): 0 Owner/Creator, Session Id (o): - 6735673 6735673 IN IP4 192.168.100.55 Owner Username: - Session ID: 6735673 Session Version: 6735673 Owner Network Type: IN Owner Address Type: IP4 Owner Address: 192.168.100.55 Session Name (s): - Connection Information (c): IN IP4 AA.AA.AA.AAAA.AA.AA.AA Connection Network Type: IN Connection Address Type: IP4 Connection Address: AA.AA.AA.AAAA.AA.AA.AA <---------- BUG????????
----- Original Message ----- From: Alberto To: serusers@lists.iptel.org Sent: Thursday, September 22, 2005 10:55 AM Subject: [Serusers] One path of RTP traffic
Hi, I have a SER + Mediaproxy. I have not any problem the call between SIP clients (behind or not the NATs) but when I try to call to PSTN (via cisco) I only have RTP traffic from SIP client to PSTN.
Summarizing, the path of rtp traffic would have to be from:
up: SIP Client ----> SER ---> GW-PSTN down: SIP Client <---- SER <--- GW-PSTNbut, really is:
up: SIP Client ----> SER ---> GW-PSTN down: SIP Client <------------- GW-PSTNI use the command:
rewritehostport("212.xxx.xxx.xxx:5060");when I match a geographic number.
The complete scheme is:
SIP Client ---- NAT --------- SER+Mediaproxy -------- SIP Server--- GWPSTN
Some idea?
Thanks,
Thank you very much....... I owe you a beer (or juice)
The problem was the line 272 ( of onSIP SER Getting Started, PSTN Gateway).Each time we call the function route(5) we have called previously the route(4) but inside of the function route(5) there are a call to the function route(4) another time, I called two times the route(4) as your you said.
Best Regards,
-- Alberto
----- Original Message ----- From: Greger V. Teigre To: Alberto ; serusers@lists.iptel.org Sent: Thursday, September 22, 2005 3:40 PM Subject: Re: [Serusers] One path of RTP traffic (possible bug?????)
You probably call fix_nated_sdp() twice in your config. g-)
---- Original Message ---- From: Alberto To: Alberto ; serusers@lists.iptel.org Sent: Thursday, September 22, 2005 01:09 PM Subject: Re: [Serusers] One path of RTP traffic (possible bug?????)
I have examine the packet INVITE and have seen the next:
AA.AA.AA.AA = public IP address of SER/Mediaproxy Server. BB.BB.BB.BB = public IP address of endpoint (the endopoint is behind nat) CC.CC.CC.CC = public IP address of SIP SERVER(carrier)
When the SER follows the INVITE message, rewrites the field Contact and fill it with the public ip address of sip client. Can this to be my problem?
In this same message into SDP, in Contact information, the SER change this field BUT write the ip address two times. Can this a bug?
Thank at all,
Alberto
INVITE from endpoint to SER: Session Initiation Protocol Request-Line: INVITE sip:932215863@AA.AA.AA.AA SIP/2.0 Method: INVITE Resent Packet: False Message Header Via: SIP/2.0/UDP 192.168.100.55:5060;branch=z9hG4bK-63bf38d4;rport From: sip:1000@AA.AA.AA.AA;tag=c1342f3464087414o0 To: sip:932215863@AA.AA.AA.AA Call-ID: d7eca5b4-6a866f94@192.168.100.55 CSeq: 102 INVITE Max-Forwards: 70 Contact: sip:1000@192.168.100.55:5060 Expires: 240 User-Agent: Linksys/PAP2-2.0.12(LS) Content-Length: 428 Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER Supported: x-sipura Content-Type: application/sdp Message body Session Description Protocol Session Description Protocol Version (v): 0 Owner/Creator, Session Id (o): - 6735673 6735673 IN IP4 192.168.100.55 Owner Username: - Session ID: 6735673 Session Version: 6735673 Owner Network Type: IN Owner Address Type: IP4 Owner Address: 192.168.100.55 Session Name (s): - Connection Information (c): IN IP4 192.168.100.55 Connection Network Type: IN Connection Address Type: IP4 Connection Address: 192.168.100.55 ........................
INVITE from SER to SIP SERVER(CARRIER): Session Initiation Protocol Request-Line: INVITE sip:932215863@CC.CC.CC.CC:5060 SIP/2.0 Method: INVITE Resent Packet: False Message Header Record-Route: sip:932215863@AA.AA.AA.AA:5060;nat=yes;ftag=c1342f3464087414o0;lr=on Via: SIP/2.0/UDP AA.AA.AA.AA;branch=z9hG4bKa01c.50c2aac6.0 Via: SIP/2.0/UDP 192.168.100.55:5060;received=BB.BB.BB.BB;branch=z9hG4bK-63bf38d4;rport=60413 From: sip:1000@AA.AA.AA.AA;tag=c1342f3464087414o0 To: sip:932215863@AA.AA.AA.AA Call-ID: d7eca5b4-6a866f94@192.168.100.55 CSeq: 102 INVITE Max-Forwards: 16 Contact: sip:1000@BB.BB.BB.BB:60413 Expires: 240 User-Agent: Linksys/PAP2-2.0.12(LS) Content-Length: 445 Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER Supported: x-sipura Content-Type: application/sdp Message body Session Description Protocol Session Description Protocol Version (v): 0 Owner/Creator, Session Id (o): - 6735673 6735673 IN IP4 192.168.100.55 Owner Username: - Session ID: 6735673 Session Version: 6735673 Owner Network Type: IN Owner Address Type: IP4 Owner Address: 192.168.100.55 Session Name (s): - Connection Information (c): IN IP4 AA.AA.AA.AAAA.AA.AA.AA Connection Network Type: IN Connection Address Type: IP4 Connection Address: AA.AA.AA.AAAA.AA.AA.AA <---------- BUG????????
----- Original Message ----- From: Alberto To: serusers@lists.iptel.org Sent: Thursday, September 22, 2005 10:55 AM Subject: [Serusers] One path of RTP traffic
Hi, I have a SER + Mediaproxy. I have not any problem the call between SIP clients (behind or not the NATs) but when I try to call to PSTN (via cisco) I only have RTP traffic from SIP client to PSTN.
Summarizing, the path of rtp traffic would have to be from:
up: SIP Client ----> SER ---> GW-PSTN down: SIP Client <---- SER <--- GW-PSTNbut, really is:
up: SIP Client ----> SER ---> GW-PSTN down: SIP Client <------------- GW-PSTNI use the command:
rewritehostport("212.xxx.xxx.xxx:5060");when I match a geographic number.
The complete scheme is:
SIP Client ---- NAT --------- SER+Mediaproxy -------- SIP Server--- GWPSTN
Some idea?
Thanks,
Hm, a beer is fine ;-) However, maybe I'm the one owing you one. Are you saying that an unmodified version of the onsip config file has this issue (that route(4) is called twice)? g-( ----- Original Message ----- From: Alberto To: Greger V. Teigre ; serusers@lists.iptel.org Sent: Thursday, September 22, 2005 05:08 PM Subject: Re: [Serusers] One path of RTP traffic (possible bug?????)
Thank you very much....... I owe you a beer (or juice)
The problem was the line 272 ( of onSIP SER Getting Started, PSTN Gateway).Each time we call the function route(5) we have called previously the route(4) but inside of the function route(5) there are a call to the function route(4) another time, I called two times the route(4) as your you said.
Best Regards,
-- Alberto
----- Original Message ----- From: Greger V. Teigre To: Alberto ; serusers@lists.iptel.org Sent: Thursday, September 22, 2005 3:40 PM Subject: Re: [Serusers] One path of RTP traffic (possible bug?????)
You probably call fix_nated_sdp() twice in your config. g-)
---- Original Message ---- From: Alberto To: Alberto ; serusers@lists.iptel.org Sent: Thursday, September 22, 2005 01:09 PM Subject: Re: [Serusers] One path of RTP traffic (possible bug?????)
> I have examine the packet INVITE and have seen the next: > > AA.AA.AA.AA = public IP address of SER/Mediaproxy Server. > BB.BB.BB.BB = public IP address of endpoint (the endopoint is behind > nat) > CC.CC.CC.CC = public IP address of SIP SERVER(carrier) > > When the SER follows the INVITE message, rewrites the field Contact > and > fill it with the public ip address of sip client. Can this to be my > problem? > > In this same message into SDP, in Contact information, the SER change > this field BUT write the > ip address two times. Can this a bug? > > Thank at all, > -- > Alberto > > ---------------- > INVITE from endpoint to SER: > Session Initiation Protocol > Request-Line: INVITE sip:932215863@AA.AA.AA.AA SIP/2.0 > Method: INVITE > Resent Packet: False > Message Header > Via: SIP/2.0/UDP > 192.168.100.55:5060;branch=z9hG4bK-63bf38d4;rport > From: sip:1000@AA.AA.AA.AA;tag=c1342f3464087414o0 > To: sip:932215863@AA.AA.AA.AA > Call-ID: d7eca5b4-6a866f94@192.168.100.55 > CSeq: 102 INVITE > Max-Forwards: 70 > Contact: sip:1000@192.168.100.55:5060 > Expires: 240 > User-Agent: Linksys/PAP2-2.0.12(LS) > Content-Length: 428 > Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER > Supported: x-sipura > Content-Type: application/sdp > Message body > Session Description Protocol > Session Description Protocol Version (v): 0 > Owner/Creator, Session Id (o): - 6735673 6735673 IN IP4 > 192.168.100.55 > Owner Username: - > Session ID: 6735673 > Session Version: 6735673 > Owner Network Type: IN > Owner Address Type: IP4 > Owner Address: 192.168.100.55 > Session Name (s): - > Connection Information (c): IN IP4 192.168.100.55 > Connection Network Type: IN > Connection Address Type: IP4 > Connection Address: 192.168.100.55 > ........................ > > INVITE from SER to SIP SERVER(CARRIER): > Session Initiation Protocol > Request-Line: INVITE sip:932215863@CC.CC.CC.CC:5060 SIP/2.0 > Method: INVITE > Resent Packet: False > Message Header > Record-Route: > sip:932215863@AA.AA.AA.AA:5060;nat=yes;ftag=c1342f3464087414o0;lr=on > Via: SIP/2.0/UDP AA.AA.AA.AA;branch=z9hG4bKa01c.50c2aac6.0 > Via: SIP/2.0/UDP > 192.168.100.55:5060;received=BB.BB.BB.BB;branch=z9hG4bK-63bf38d4;rport=60413 > From: sip:1000@AA.AA.AA.AA;tag=c1342f3464087414o0 > To: sip:932215863@AA.AA.AA.AA > Call-ID: d7eca5b4-6a866f94@192.168.100.55 > CSeq: 102 INVITE > Max-Forwards: 16 > Contact: sip:1000@BB.BB.BB.BB:60413 > Expires: 240 > User-Agent: Linksys/PAP2-2.0.12(LS) > Content-Length: 445 > Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER > Supported: x-sipura > Content-Type: application/sdp > Message body > Session Description Protocol > Session Description Protocol Version (v): 0 > Owner/Creator, Session Id (o): - 6735673 6735673 IN IP4 > 192.168.100.55 > Owner Username: - > Session ID: 6735673 > Session Version: 6735673 > Owner Network Type: IN > Owner Address Type: IP4 > Owner Address: 192.168.100.55 > Session Name (s): - > Connection Information (c): IN IP4 AA.AA.AA.AAAA.AA.AA.AA > Connection Network Type: IN > Connection Address Type: IP4 > Connection Address: AA.AA.AA.AAAA.AA.AA.AA > <---------- BUG???????? > > > ----- Original Message ----- > From: Alberto > To: serusers@lists.iptel.org > Sent: Thursday, September 22, 2005 10:55 AM > Subject: [Serusers] One path of RTP traffic > > > Hi, > I have a SER + Mediaproxy. I have not any problem the call between > SIP clients (behind or not the NATs) > but when I try to call to PSTN (via cisco) I only have RTP traffic > from SIP client to PSTN. > > Summarizing, the path of rtp traffic would have to be from: > > up: SIP Client ----> SER ---> GW-PSTN > down: SIP Client <---- SER <--- GW-PSTN > > but, really is: > > up: SIP Client ----> SER ---> GW-PSTN > down: SIP Client <------------- GW-PSTN > > I use the command: > > rewritehostport("212.xxx.xxx.xxx:5060"); > > when I match a geographic number. > > The complete scheme is: > > SIP Client ---- NAT --------- SER+Mediaproxy -------- SIP Server > --- GWPSTN > > > > Some idea? > > Thanks,
Greger V. Teigre wrote:
saying that an unmodified version of the onsip config file has this issue (that route(4) is called twice)?
I also encountered this problem last week when trying out how the onsip-config manages PSTN calls. But I've already suppressed it (the issue, not the config ;o)
The quick fix was to protect use_media_proxy() with a flag...
Andy
But the config already has a protection of use_media_proxy() with a flag?! Or maybe you are referring to an earlier config and not the features-callfwd.cfg one? g-)
----- Original Message ----- From: "Andreas Granig" andreas.granig@inode.info To: "Greger V. Teigre" greger@teigre.com Cc: "Alberto" alberto.ipt@telefonica.net; serusers@lists.iptel.org Sent: Thursday, September 22, 2005 08:05 PM Subject: Re: [Serusers] One path of RTP traffic (possible bug?????)
Greger V. Teigre wrote:
saying that an unmodified version of the onsip config file has this issue (that route(4) is called twice)?
I also encountered this problem last week when trying out how the onsip-config manages PSTN calls. But I've already suppressed it (the issue, not the config ;o)
The quick fix was to protect use_media_proxy() with a flag...
Andy
Greger V. Teigre wrote:
But the config already has a protection of use_media_proxy() with a flag?! Or maybe you are referring to an earlier config and not the features-callfwd.cfg one?
I'm referring to the config in chapter 8 in gettingstarted-05. In route[4] you have the following code:
if (isflagset(6) || isflagset(7)) { use_media_proxy(); };
But I have accustomed to protect it like this:
if (!isflagset(8) && (isflagset(6) || isflagset(7))) { setflag(8); use_media_proxy(); };
So it can only be called once.
Andy
Thanks. The same protection has been applied to features-callfwd.cfg. I have added an issue: https://siprouter.onsip.org/trac/ticket/11 g-) ----- Original Message ----- From: "Andreas Granig" andreas.granig@inode.info To: "Greger V. Teigre" greger@teigre.com Cc: "Alberto" alberto.ipt@telefonica.net; serusers@lists.iptel.org Sent: Friday, September 23, 2005 10:23 AM Subject: Re: [Serusers] One path of RTP traffic (possible bug?????)
Greger V. Teigre wrote:
But the config already has a protection of use_media_proxy() with a flag?! Or maybe you are referring to an earlier config and not the features-callfwd.cfg one?
I'm referring to the config in chapter 8 in gettingstarted-05. In route[4] you have the following code:
if (isflagset(6) || isflagset(7)) { use_media_proxy(); };
But I have accustomed to protect it like this:
if (!isflagset(8) && (isflagset(6) || isflagset(7))) { setflag(8); use_media_proxy(); };
So it can only be called once.
Andy
-
Alberto -
Andreas Granig -
Greger V. Teigre