Hi @ all,
I am fighting a pretty annoying problem at the moment.
As described in rfc3261 / 13.2.1 Creating the Initial INVITE
o The initial offer MUST be in either an INVITE or, if not there, in the first reliable non-failure message from the UAS back to the UAC. In this specification, that is the final 2xx response.
My problem is the following:
I receive a initial INVITE without SDP, forward it to a PSTN Gateway.
From the Gateway I receive the 200 OK with SDP offer.
In the onreply_route I make a call to the mediaproxy use_media_proxy();
Unfortunately use_media_proxy() seems to make a lookup command when used in a reply route.
I would need to make a request command which would create the media session and then do a lookup with the ACK from the UAC.
Is there a way around this?
cheers,
Patrick.
This e-mail is confidential and may well also be legally privileged. If you have received it in error, you are on notice of its status. Please notify us immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person: to do so could be a breach of confidence. Thank you for your cooperation. Information pursuant to paragraph 14 Austrian Companies Code: UPC Austria GmbH; Registered Office: Wolfganggasse 58-60, 1120 Vienna Company Register Number: FN 189858d at the Commercial Court of Vienna
hmmz found someting interesting :)
http://mediaproxy.ag-projects.com/Changelog
Changes from version 1.8.1 to 1.8.2 -----------------------------------
- Added support to setup sessions by either caller or called as the initial INVITE may not contain a SDP body (Jeff Williams jeffw@globaldial.com)
cheers,
Patrick.
Hi @ all,
I am fighting a pretty annoying problem at the moment.
As described in rfc3261 / 13.2.1 Creating the Initial INVITE
o The initial offer MUST be in either an INVITE or, if not there, in the first reliable non-failure message from the UAS back to the UAC. In this specification, that is the final 2xx response.My problem is the following:
I receive a initial INVITE without SDP, forward it to a PSTN Gateway. From the Gateway I receive the 200 OK with SDP offer.
In the onreply_route I make a call to the mediaproxy use_media_proxy();
Unfortunately use_media_proxy() seems to make a lookup command when used in a reply route.
I would need to make a request command which would create the media session and then do a lookup with the ACK from the UAC.
Is there a way around this?
cheers,
Patrick.
This e-mail is confidential and may well also be legally privileged. If you have received it in error, you are on notice of its status. Please notify us immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person: to do so could be a breach of confidence. Thank you for your cooperation. Information pursuant to paragraph 14 Austrian Companies Code: UPC Austria GmbH; Registered Office: Wolfganggasse 58-60, 1120 Vienna Company Register Number: FN 189858d at the Commercial Court of Vienna
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
--
Patrick Miccio UPC ECC Core ISP Services
UPC Austria GmbH Center Ost, St. Peter Gürtel 10b A-8042 Graz T +43 (0) 59 999 0 E pmiccio@upcbroadband.com
This e-mail is confidential and may well also be legally privileged. If you have received it in error, you are on notice of its status. Please notify us immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person: to do so could be a breach of confidence. Thank you for your cooperation. Information pursuant to paragraph 14 Austrian Companies Code: UPC Austria GmbH; Registered Office: Wolfganggasse 58-60, 1120 Vienna Company Register Number: FN 189858d at the Commercial Court of Vienna
Hi Patrick, I have exactly the same problem as you and also found this information. However I haven't been able to make it works yet (and I have Mediaproxy 1.9.0)
In my case, I can see after receiving the 200 OK message with SDP that the Openser tries to use the mediaproxy, however the mediaproxy doesn't answer. HAve a look at the log. The calling party has a public IP (it's actually a gateway and isn't attach to the Openser) and the called is behind Nat and logged in the Openser. It'd be great if you could find a solution!!!
5(1583) DEBUG:tm:relay_reply: sent buf=0x813ada8: SIP/2.0 1..., shmem=0xb6122468: SIP/2.0 1
5(1583) DBG: trans=0xb6120e90, callback type 128, id 0 entered
5(1583) DEBUG: add_to_tail_of_timer[1]: 0xb6120fbc
5(1583) DEBUG:destroy_avp_list: destroying list (nil)
5(1583) receive_msg: cleaning up
18(1596) DEBUG: timer routine:4,tl=0xb6120fac next=(nil)
9(*1587) SIP Reply (status):
9(1587) version: <SIP/2.0>
9(1587) status: <200>
9(1587) reason: <OK>
*
9(1587) parse_headers: flags=2
9(1587) Found param type 232, <branch> = <z9hG4bK91b2.2ff8dc12.0>; state=16
9(1587) end of header reached, state=5
9(1587) parse_headers: Via found, flags=2
9(1587) parse_headers: this is the first via
9(1587) After parse_msg...
9(1587) forward_reply: found module tm, passing reply to it
9(1587) DEBUG: t_check: msg id=1 global id=0 T start=0xffffffff
9(1587) parse_headers: flags=22
9(1587) Found param type 235, <rport> = <5060>; state=6
9(1587) Found param type 232, <branch> = < z9hG4bKb05f1b5007f0cdf7eb5ed7a2d75c1865.1>; state=16
9(1587) end of header reached, state=5
9(1587) parse_headers: Via found, flags=22
9(1587) parse_headers: this is the second via
9(1587) DEBUG: add_param: tag=456e5e76
9(1587) DEBUG:parse_to:end of header reached, state=29
9(1587) DEBUG: get_hdr_field: <To> [37]; uri=[sip:img2@xxx.xxx.10.13]
9(1587) DEBUG: to body [sip:img2@xxx.xxx.10.13]
9(1587) get_hdr_field: cseq <CSeq>: <100> <INVITE>
9(1587) parse_headers: flags=8
9(1587) DEBUG: t_reply_matching: hash 11033 label 567119858 branch 0
9(1587) DEBUG: t_reply_matching: reply matched (T=0xb6120e90)!
9(1587) parse_headers: flags=8
9(1587) DBG: trans=0xb6120e90, callback type 2, id 0 entered
9(1587) parse_headers: flags=8
9(1587) DEBUG: t_check: msg id=1 global id=1 T end=0xb6120e90
9(1587) DEBUG:tm:reply_received: org. status uas=180, uac[0]=180 local=0 is_invite=1)
9(1587) parse_headers: flags=80
9(1587) parse_headers: flags=80
9(1587) parse_headers: flags=4000000
9(1587) DEBUG: get_hdr_body : content_length=433
9(1587) found end of header
9(1587) parse_headers: flags=ffffffffffffffff
9(1587) DEBUG: add_param: tag=d4804fd95a98a284
9(1587) DEBUG:parse_to:end of header reached, state=29
9(1587) is_local(): Realm 'xxx.xxx.10.11' is not local
9(1587) parse_headers: flags=4000000
9(1587) *error: use_media_proxy(): empty response from mediaproxy
*
9(1587) DEBUG:tm:t_should_relay_response: T_code=180, new_code=200
9(1587) DEBUG:tm:relay_reply: branch=0, save=0, relay=0
9(1587) old size: 926, new size: 860
9(1587) build_res_from_sip_res: copied size: orig:436, new: 370, rest: 490 msg= *
SIP/2.0 200 OK
*
Via: SIP/2.0/UDP xxx.xxx.10.11:5060;rport=5060;branch= z9hG4bKb05f1b5007f0cdf7eb5ed7a2d75c1865.1
To: sip:img2@xxx.xxx.10.13;tag=456e5e76
From: "test" sip:test@xxx.xxx.10.11;tag=d4804fd95a98a284
Call-ID: 7efaaddc416e0975@xxx.xxx.10.11
CSeq: 100 INVITE
Server: UtoPIA TNO/Sceneware
Record-Route: sip:xxx.xxx.10.13;lr
Contact: sip:img2@87.220.61.76:10613
Content-Type: application/sdp
Content-Length: 433
v=0
o=img2 0 0 IN IP4 192.168.1.131
s=UtoPIA session
c=IN IP4 192.168.1.131
t=3409923663 0
m=audio 8888 RTP/AVP 96 0 8 13
a=rtpmap:96 AMR/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:13 CN/8000
a=fmtp:96 octet-align
m=video 6054 RTP/AVP 98 99 34
b=AS:192
a=rtpmap:98 H263-1998/90000
a=rtpmap:99 H263-2000/90000
a=rtpmap:34 H263/90000
a=fmtp:98 CIF=2;QCIF=2
a=fmtp:99 CIF=2;QCIF=2
a=fmtp:34 CIF=2;QCIF=2
2008/1/23, Patrick Miccio pmiccio@upcbroadband.com:
hmmz found someting interesting :)
http://mediaproxy.ag-projects.com/Changelog
Changes from version 1.8.1 to 1.8.2
- Added support to setup sessions by either caller or called as the
initial INVITE may not contain a SDP body (Jeff Williams jeffw@globaldial.com)
cheers,
Patrick.
Hi @ all,
I am fighting a pretty annoying problem at the moment.
As described in rfc3261 / 13.2.1 Creating the Initial INVITE
o The initial offer MUST be in either an INVITE or, if not there, in the first reliable non-failure message from the UAS back to the UAC. In this specification, that is the final 2xx response.My problem is the following:
I receive a initial INVITE without SDP, forward it to a PSTN Gateway. From the Gateway I receive the 200 OK with SDP offer.
In the onreply_route I make a call to the mediaproxy use_media_proxy();
Unfortunately use_media_proxy() seems to make a lookup command when used
in a reply route.
I would need to make a request command which would create the media
session and then do a lookup with the ACK from the
UAC.
Is there a way around this?
cheers,
Patrick.
This e-mail is confidential and may well also be legally privileged. If
you have received it in error, you are on
notice of its status. Please notify us immediately by reply e-mail and
then delete this message from your system.
Please do not copy it or use it for any purposes, or disclose its
contents to any other person: to do so could be a
breach of confidence. Thank you for your cooperation. Information
pursuant to paragraph 14 Austrian Companies Code:
UPC Austria GmbH; Registered Office: Wolfganggasse 58-60, 1120 Vienna
Company Register Number: FN 189858d at the
Commercial Court of Vienna
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
--
Patrick Miccio UPC ECC Core ISP Services
UPC Austria GmbH Center Ost, St. Peter Gürtel 10b A-8042 Graz T +43 (0) 59 999 0 E pmiccio@upcbroadband.com
This e-mail is confidential and may well also be legally privileged. If you have received it in error, you are on notice of its status. Please notify us immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person: to do so could be a breach of confidence. Thank you for your cooperation. Information pursuant to paragraph 14 Austrian Companies Code: UPC Austria GmbH; Registered Office: Wolfganggasse 58-60, 1120 Vienna Company Register Number: FN 189858d at the Commercial Court of Vienna
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
Ok,
as far as I understood everything correctly the mediaproxy module seems to be the problem.
mediaproxy.c contains the following code:
if (msg->first_line.type == SIP_REQUEST) { request = True; } else if (msg->first_line.type == SIP_REPLY) { request = False; } else { return -1; }
that means that in a reply route "request" will always be "False" and use_media_proxy() will result in a lookup command, the proxydispatcher however expects a request command to create sessions according to mediaproxy/modules/dispatcher.py
The nathelper module from openser offers the force_rtp_proxy("s") command, a functionality that would be welcome in mediaproxy module unless you one could call the proxydispatcher from the nathelper module.
If I got anything wrong please correct me.
cheers,
Patrick.
This e-mail is confidential and may well also be legally privileged. If you have received it in error, you are on notice of its status. Please notify us immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person: to do so could be a breach of confidence. Thank you for your cooperation. Information pursuant to paragraph 14 Austrian Companies Code: UPC Austria GmbH; Registered Office: Wolfganggasse 58-60, 1120 Vienna Company Register Number: FN 189858d at the Commercial Court of Vienna
Thanks,
I've been checking the proxydispatcher log and what I see is: lookup 5ecf1d19b23bdea6@xxx.xxx.10.11 192.168.1.131:3918:audio, 192.168.1.131:13598:video 87.220.61.76 xxx.xxx.10.11 remote xxx.xxx.10.13unknown UtoPIA=20TNO/Sceneware info= from:test@xxx.xxx.10.11,to:img2@xxx.xxx.10.13 ,fromtag:b61e31363043b636,totag:98af7baa
request 5ecf1d19b23bdea6@xxx.xxx.10.11 xxx.xxx.10.11:25968:audio, xxx.xxx.10.11:25970:video xxx.xxx.10.11 xxx.xxx.10.11 remote xxx.220.61.76remote TANDBERG/37=20(V3Beta0) info= from:test@xxx.xxx.10.11,to:img2@xxx.xxx.10.13 ,fromtag:b61e31363043b636,totag:98af7baa Regarding the force_rtp_proxy("s") should be used with RTP Proxy but no with MediaProxy? Am I right?
M
2008/1/24, Patrick Miccio pmiccio@upcbroadband.com:
Ok,
as far as I understood everything correctly the mediaproxy module seems to be the problem.
mediaproxy.c contains the following code:
if (msg->first_line.type == SIP_REQUEST) { request = True; } else if (msg->first_line.type == SIP_REPLY) { request = False; } else { return -1; }
that means that in a reply route "request" will always be "False" and use_media_proxy() will result in a lookup command, the proxydispatcher however expects a request command to create sessions according to mediaproxy/modules/dispatcher.py
The nathelper module from openser offers the force_rtp_proxy("s") command, a functionality that would be welcome in mediaproxy module unless you one could call the proxydispatcher from the nathelper module.
If I got anything wrong please correct me.
cheers,
Patrick.
This e-mail is confidential and may well also be legally privileged. If you have received it in error, you are on notice of its status. Please notify us immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person: to do so could be a breach of confidence. Thank you for your cooperation. Information pursuant to paragraph 14 Austrian Companies Code: UPC Austria GmbH; Registered Office: Wolfganggasse 58-60, 1120 Vienna Company Register Number: FN 189858d at the Commercial Court of Vienna
Hey,
your log shows the "lookup" from the 200 OK coming from the UAS, and the "request" from the ACK coming from the UAC, its the same here :(
and yeah force_rtp_proxy only works with nathelper/rtpproxy.
cheers,
Patrick.
Thanks,
I've been checking the proxydispatcher log and what I see is: lookup 5ecf1d19b23bdea6@xxx.xxx.10.11mailto:5ecf1d19b23bdea6@xxx.xxx.10.11 192.168.1.131:3918http://192.168.1.131:3918:audio,192.168.1.131:13598http://192.168.1.131:13598:video 87.220.61.76http://87.220.61.76 xxx.xxx.10.11 remote xxx.xxx.10.13 unknown UtoPIA=20TNO/Sceneware info=from:test@xxx.xxx.10.11mailto:from:test@xxx.xxx.10.11,to:img2@xxx.xxx.10.13mailto:to:img2@xxx.xxx.10.13,fromtag:b61e31363043b636,totag:98af7baa
request 5ecf1d19b23bdea6@xxx.xxx.10.11mailto:5ecf1d19b23bdea6@xxx.xxx.10.11 xxx.xxx.10.11:25968:audio,xxx.xxx.10.11:25970:video xxx.xxx.10.11 xxx.xxx.10.11 remote xxx.220.61.76 remote TANDBERG/37=20(V3Beta0) info=from:test@xxx.xxx.10.11mailto:from:test@xxx.xxx.10.11,to:img2@xxx.xxx.10.13mailto:to:img2@xxx.xxx.10.13,fromtag:b61e31363043b636,totag:98af7baa
Regarding the force_rtp_proxy("s") should be used with RTP Proxy but no with MediaProxy? Am I right?
M
2008/1/24, Patrick Miccio <pmiccio@upcbroadband.commailto:pmiccio@upcbroadband.com>: Ok,
as far as I understood everything correctly the mediaproxy module seems to be the problem.
mediaproxy.c contains the following code:
if (msg->first_line.type == SIP_REQUEST) { request = True; } else if (msg->first_line.type == SIP_REPLY) { request = False; } else { return -1; }
that means that in a reply route "request" will always be "False" and use_media_proxy() will result in a lookup command, the proxydispatcher however expects a request command to create sessions according to mediaproxy/modules/dispatcher.py
The nathelper module from openser offers the force_rtp_proxy("s") command, a functionality that would be welcome in mediaproxy module unless you one could call the proxydispatcher from the nathelper module.
If I got anything wrong please correct me.
cheers,
Patrick.
This e-mail is confidential and may well also be legally privileged. If you have received it in error, you are on notice of its status. Please notify us immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person: to do so could be a breach of confidence. Thank you for your cooperation. Information pursuant to paragraph 14 Austrian Companies Code: UPC Austria GmbH; Registered Office: Wolfganggasse 58-60, 1120 Vienna Company Register Number: FN 189858d at the Commercial Court of Vienna
This e-mail is confidential and may well also be legally privileged. If you have received it in error, you are on notice of its status. Please notify us immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person: to do so could be a breach of confidence. Thank you for your cooperation. Information pursuant to paragraph 14 Austrian Companies Code: UPC Austria GmbH; Registered Office: Wolfganggasse 58-60, 1120 Vienna Company Register Number: FN 189858d at the Commercial Court of Vienna
Hi Patrick,
yes, the nathelper module has the capability to deal with SDP negotiation via 200 OK / ACK by using the "s" flag, as Mario pointed out.
Regards, Bogdan
Patrick Miccio wrote:
Hey,
your log shows the "lookup" from the 200 OK coming from the UAS, and the "request" from the ACK coming from the UAC, its the same here :(
and yeah force_rtp_proxy only works with nathelper/rtpproxy.
cheers,
Patrick.
Thanks,
I've been checking the proxydispatcher log and what I see is: lookup 5ecf1d19b23bdea6@xxx.xxx.10.11mailto:5ecf1d19b23bdea6@xxx.xxx.10.11 192.168.1.131:3918http://192.168.1.131:3918:audio,192.168.1.131:13598http://192.168.1.131:13598:video 87.220.61.76http://87.220.61.76 xxx.xxx.10.11 remote xxx.xxx.10.13 unknown UtoPIA=20TNO/Sceneware info=from:test@xxx.xxx.10.11mailto:from:test@xxx.xxx.10.11,to:img2@xxx.xxx.10.13mailto:to:img2@xxx.xxx.10.13,fromtag:b61e31363043b636,totag:98af7baa
request 5ecf1d19b23bdea6@xxx.xxx.10.11mailto:5ecf1d19b23bdea6@xxx.xxx.10.11 xxx.xxx.10.11:25968:audio,xxx.xxx.10.11:25970:video xxx.xxx.10.11 xxx.xxx.10.11 remote xxx.220.61.76 remote TANDBERG/37=20(V3Beta0) info=from:test@xxx.xxx.10.11mailto:from:test@xxx.xxx.10.11,to:img2@xxx.xxx.10.13mailto:to:img2@xxx.xxx.10.13,fromtag:b61e31363043b636,totag:98af7baa
Regarding the force_rtp_proxy("s") should be used with RTP Proxy but no with MediaProxy? Am I right?
M
2008/1/24, Patrick Miccio <pmiccio@upcbroadband.commailto:pmiccio@upcbroadband.com>: Ok,
as far as I understood everything correctly the mediaproxy module seems to be the problem.
mediaproxy.c contains the following code:
if (msg->first_line.type == SIP_REQUEST) { request = True; } else if (msg->first_line.type == SIP_REPLY) { request = False; } else { return -1; }
that means that in a reply route "request" will always be "False" and use_media_proxy() will result in a lookup command, the proxydispatcher however expects a request command to create sessions according to mediaproxy/modules/dispatcher.py
The nathelper module from openser offers the force_rtp_proxy("s") command, a functionality that would be welcome in mediaproxy module unless you one could call the proxydispatcher from the nathelper module.
If I got anything wrong please correct me.
cheers,
Patrick.
-
Bogdan-Andrei Iancu -
Mario Bedialauneta -
Patrick Miccio