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(a)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(a)upcbroadband.com>om>:
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(a)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(a)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(a)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(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users