[OpenSER-Users] Intial INVITES without SDP

Mario Bedialauneta mbedial at gmail.com
Wed Jan 23 18:48:38 CET 2008


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 at xxx.xxx.10.13]

9(1587) DEBUG: to body [<sip:img2 at 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 at xxx.xxx.10.13>;tag=456e5e76

From: "test" <sip:test at xxx.xxx.10.11>;tag=d4804fd95a98a284

Call-ID: 7efaaddc416e0975 at xxx.xxx.10.11

CSeq: 100 INVITE

Server: UtoPIA TNO/Sceneware

Record-Route: <sip:xxx.xxx.10.13;lr>

Contact: <sip:img2 at 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 at 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 at 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 at 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 at 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 at lists.openser.org
> http://lists.openser.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kamailio.org/pipermail/users/attachments/20080123/6f91ba7f/attachment.htm 


More information about the Users mailing list