Re: [OpenSIPS-Users] Asterisk reinvite confuses Mediaproxy
Hi Ruud, On 7/21/09 11:52 AM, "Ruud Klaver" wrote: > Is there any particular reason why you need Asterisk inbetween? In any > case, I suppose you could disable re-INVITEs in asterisk. The > implementation of it seems to be a bit of a hack. Well, yes. We're working on a replacement for the Asterisk piece altogether. It is a legacy component. For now, we need to come up with something. > It's an interesting case, but I hope you can deal with it somehow. It may be another, temporary Asterisk install. Yuck. We'll come up with something. - Jeff ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Asterisk reinvite confuses Mediaproxy
Hi Jeff, On 21 Jul 2009, at 17:17, Jeff Pyle wrote: > Hi Ruud, > > On 7/20/09 6:29 AM, "Ruud Klaver" wrote: > >> What I said is still valid, both endpoints SHOULD start sending to >> the >> new ip/port destination after the re-INVITE transaction has finished. >> Looking at the mediaproxy logs you sent, all is fine up to the point >> where the caller is about to receive the 200 OK for the re-INVITE. >> After it did receive it, mediaproxy-relay display the following line: >> >> debug: Got traffic information for stream: (audio) 44.55.66.30:13504 >> (RTP: 22.33.44.82:28140, RTCP: Unknown) <-> 22.33.44.89:16392 <-> >> 22.33.44.89:16394 <-> 33.44.55.122:17328 (RTP: 33.44.55.122:17328, >> RTCP: Unknown) >> >> You can see that the relay got RTP from the caller side from the old >> ip/port, that is the asterisk box, while in the re-INVITE it proposed >> to change this to 44.55.66.30:13504. This must mean that asterisk >> takes the ip/port from the 200 OK, which is newly allocated on the >> relay, and starts sending to this directly. What should have happened >> is that asterisk informs the endpoint (through its own re-INVITE?) >> that of the new port/ip so that this endpoint could send to it >> directly, without asterisk sending to it first. Because asterisk did >> start sending to it itself, the relay locks in the source ip/port for >> this stream and will ignore other UDP traffic sent to this port. > > It took me a few more test calls and a lot of crunch time to wrap my > mind > around what you had said. > > I believe I've finally found what you're talking about. In another > call, I > saw in a media capture the Asterisk box had "dribbled" about 8 RTP > packets > to the new, post-reINVITE ip/port on the relay before its RTP stops > and the > PSTN gateway's RTP starts. But, as you've mentioned, by this time > it's too > late because the relay has locked in the Asterisk box's IP/port and > the PSTN > gateway RTP is ignored. I imagine this is because of the processing > lag in > the reinvite on the PSTN gateway-side of the Asterisk box. Perhaps it's because it does the proxy-side re-INVITE first, using the UDP ip/port it knows from the RTP stream it's relaying, and only then sends a re-INVITE on the PSTN gateway side, continuing to relay the RTP packets to the new mediaproxy port in the meantime. Is there any particular reason why you need Asterisk inbetween? In any case, I suppose you could disable re-INVITEs in asterisk. The implementation of it seems to be a bit of a hack. >> So in a sense it's asterisk that's confused by its own re-INVITE, not >> mediaproxy... > > Yes. Indeed it does. Imagine that. > > Thanks for your help. > > > - Jeff > It's an interesting case, but I hope you can deal with it somehow. Ruud Klaver AG Projects ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Asterisk reinvite confuses Mediaproxy
Hi Ruud, On 7/20/09 6:29 AM, "Ruud Klaver" wrote: > What I said is still valid, both endpoints SHOULD start sending to the > new ip/port destination after the re-INVITE transaction has finished. > Looking at the mediaproxy logs you sent, all is fine up to the point > where the caller is about to receive the 200 OK for the re-INVITE. > After it did receive it, mediaproxy-relay display the following line: > > debug: Got traffic information for stream: (audio) 44.55.66.30:13504 > (RTP: 22.33.44.82:28140, RTCP: Unknown) <-> 22.33.44.89:16392 <-> > 22.33.44.89:16394 <-> 33.44.55.122:17328 (RTP: 33.44.55.122:17328, > RTCP: Unknown) > > You can see that the relay got RTP from the caller side from the old > ip/port, that is the asterisk box, while in the re-INVITE it proposed > to change this to 44.55.66.30:13504. This must mean that asterisk > takes the ip/port from the 200 OK, which is newly allocated on the > relay, and starts sending to this directly. What should have happened > is that asterisk informs the endpoint (through its own re-INVITE?) > that of the new port/ip so that this endpoint could send to it > directly, without asterisk sending to it first. Because asterisk did > start sending to it itself, the relay locks in the source ip/port for > this stream and will ignore other UDP traffic sent to this port. It took me a few more test calls and a lot of crunch time to wrap my mind around what you had said. I believe I've finally found what you're talking about. In another call, I saw in a media capture the Asterisk box had "dribbled" about 8 RTP packets to the new, post-reINVITE ip/port on the relay before its RTP stops and the PSTN gateway's RTP starts. But, as you've mentioned, by this time it's too late because the relay has locked in the Asterisk box's IP/port and the PSTN gateway RTP is ignored. I imagine this is because of the processing lag in the reinvite on the PSTN gateway-side of the Asterisk box. > So in a sense it's asterisk that's confused by its own re-INVITE, not > mediaproxy... Yes. Indeed it does. Imagine that. Thanks for your help. - Jeff ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Asterisk reinvite confuses Mediaproxy
Hi Jeff, On 17 Jul 2009, at 22:49, Jeff Pyle wrote: > Let's try it with the attachment this time... That usually helps. ;) > On 7/17/09 4:48 PM, "Jeff Pyle" wrote: > >> Hi Ruud, >> >> Sorry for any confusion. I've attached fresh traces, including a >> full ngrep >> and mediaproxy relay and dispatcher logs. >> >> This is an inbound call from PSTN gateway to Asterisk (with >> reinvites) to >> Opensips with Mediaproxy to the callee endpoint. I have a single >> engage_media_proxy() at the initial invite. >> >> >> - Jeff >> >> >> >> >> On 7/16/09 4:15 AM, "Ruud Klaver" wrote: >> >>> Hi Jeff, >>> >>> I've just been scrutinizing your SIP trace, as you still haven't >>> provided me with mediaproxy-relay debug output. What happens when >>> the >>> SDP offerer comes with a new ip/port combination for a particular >>> stream is that mediaproxy allocates a new set of ports for this >>> internally. You can see that this happens by the fact that for the >>> re- >>> invite, the RTP port in the modified SDP is different. This means >>> that >>> both endpoints actually should start sending to a new destination >>> as a >>> result of the re-INVITE exchange. If they do, the previous RTP >>> exchange and the next one can never actually "cross wires". What I said is still valid, both endpoints SHOULD start sending to the new ip/port destination after the re-INVITE transaction has finished. Looking at the mediaproxy logs you sent, all is fine up to the point where the caller is about to receive the 200 OK for the re-INVITE. After it did receive it, mediaproxy-relay display the following line: debug: Got traffic information for stream: (audio) 44.55.66.30:13504 (RTP: 22.33.44.82:28140, RTCP: Unknown) <-> 22.33.44.89:16392 <-> 22.33.44.89:16394 <-> 33.44.55.122:17328 (RTP: 33.44.55.122:17328, RTCP: Unknown) You can see that the relay got RTP from the caller side from the old ip/port, that is the asterisk box, while in the re-INVITE it proposed to change this to 44.55.66.30:13504. This must mean that asterisk takes the ip/port from the 200 OK, which is newly allocated on the relay, and starts sending to this directly. What should have happened is that asterisk informs the endpoint (through its own re-INVITE?) that of the new port/ip so that this endpoint could send to it directly, without asterisk sending to it first. Because asterisk did start sending to it itself, the relay locks in the source ip/port for this stream and will ignore other UDP traffic sent to this port. So in a sense it's asterisk that's confused by its own re-INVITE, not mediaproxy... Ruud Klaver AG Projects ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Asterisk reinvite confuses Mediaproxy
Hi Ruud, Sorry for any confusion. I've attached fresh traces, including a full ngrep and mediaproxy relay and dispatcher logs. This is an inbound call from PSTN gateway to Asterisk (with reinvites) to Opensips with Mediaproxy to the callee endpoint. I have a single engage_media_proxy() at the initial invite. - Jeff On 7/16/09 4:15 AM, "Ruud Klaver" wrote: > Hi Jeff, > > I've just been scrutinizing your SIP trace, as you still haven't > provided me with mediaproxy-relay debug output. What happens when the > SDP offerer comes with a new ip/port combination for a particular > stream is that mediaproxy allocates a new set of ports for this > internally. You can see that this happens by the fact that for the re- > invite, the RTP port in the modified SDP is different. This means that > both endpoints actually should start sending to a new destination as a > result of the re-INVITE exchange. If they do, the previous RTP > exchange and the next one can never actually "cross wires". > > Now I'm not exactly sure what your problem is, as you said before it's > PSTN -> SIP phone that is giving you trouble, yet you've included a > trace which seems to be in the opposite direction. Again, please > include a media-relay log and describe what you are (not) hearing at > either endpoint. > > Ruud Klaver > AG Projects ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Asterisk reinvite confuses Mediaproxy
Hi Jeff, On 16 Jul 2009, at 00:37, Jeff Pyle wrote: > We're interfacing this Opensips + Mediaproxy with an existing > system. We > cannot change the existing system. Eventually this system will > contain > NAT'ed clients, hence the Mediaproxy. I didn't want to introduce > NAT until > everything was working properly without it. > > I'll try the use_media_proxy() method and see what happens. > > > - Jeff > > > On 7/12/09 5:28 AM, "Olle E. Johansson" wrote: > >> On a different note, why keep asterisk re-invites turned on if you >> use >> a media proxy in the call? >> Re-invites are best used when no NAT or firewall support is needed, >> and since you're using media proxy, it indicates to me that you might >> not want to have re-invites turned on at all. >> >> /O I've just been scrutinizing your SIP trace, as you still haven't provided me with mediaproxy-relay debug output. What happens when the SDP offerer comes with a new ip/port combination for a particular stream is that mediaproxy allocates a new set of ports for this internally. You can see that this happens by the fact that for the re- invite, the RTP port in the modified SDP is different. This means that both endpoints actually should start sending to a new destination as a result of the re-INVITE exchange. If they do, the previous RTP exchange and the next one can never actually "cross wires". Now I'm not exactly sure what your problem is, as you said before it's PSTN -> SIP phone that is giving you trouble, yet you've included a trace which seems to be in the opposite direction. Again, please include a media-relay log and describe what you are (not) hearing at either endpoint. Ruud Klaver AG Projects ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Asterisk reinvite confuses Mediaproxy
El Jueves, 16 de Julio de 2009, Jeff Pyle escribió: > We're interfacing this Opensips + Mediaproxy with an existing system. We > cannot change the existing system. Eventually this system will contain > NAT'ed clients, hence the Mediaproxy. I didn't want to introduce NAT until > everything was working properly without it. The proxy (OpenSIPS) can "fix" the signalling for natted clients and Asterisk can "fix" the media (nat=yes). -- Iñaki Baz Castillo ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Asterisk reinvite confuses Mediaproxy
We're interfacing this Opensips + Mediaproxy with an existing system. We cannot change the existing system. Eventually this system will contain NAT'ed clients, hence the Mediaproxy. I didn't want to introduce NAT until everything was working properly without it. I'll try the use_media_proxy() method and see what happens. - Jeff On 7/12/09 5:28 AM, "Olle E. Johansson" wrote: > On a different note, why keep asterisk re-invites turned on if you use > a media proxy in the call? > Re-invites are best used when no NAT or firewall support is needed, > and since you're using media proxy, it indicates to me that you might > not want to have re-invites turned on at all. > > /O > ___ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Asterisk reinvite confuses Mediaproxy
On 11 Jul 2009, at 20:29, Jeff Pyle wrote: > The only difference I can see between an inbound call and an > outbound call > from a media perspective is that in inbound has no pre-connect media > (180 > w/o SDP) while an outbound call has media (183 w/ SDP). MIght that be > relevant? > > > - Jeff The 183 may very well be relevant in this case, but I don't see a 183 in the trace you sent. As well as the SDP logs, please also post the Mediaproxy relay log for the relevant session. Ruud Klaver AG Projects ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Asterisk reinvite confuses Mediaproxy
On Sunday 12 July 2009 00:48:26 Jeff Pyle wrote: > On 7/11/09 5:33 PM, "Raúl Alexis Betancor Santana" > > wrote: > > I will not question why are you trying to use Mediaproxy if not for NAT > > fixing .. X-) > > Because I can. :) Or, rather, I thought I could... Real world > applications include more accurate accounting and documenting the codecs in > use. For accurate accounting I prefer to use a B2BUA, for documenting the codecs in use, that could be done, just with the Proxy, but you get a good idea :-) > > For properly handling the re-invite, did you call force_rtp_proxy INSIDE > > the in-dialog procces ? > > force_rtp_proxy() is for rtpproxy; this is Mediaproxy. I told you without reading the docs ... just from memory. > I'm calling only > engage_media_proxy() at the initial INVITE. I suggest you to stay appart from the dialog module as far as you can. > Perhaps I might have more luck > with the less automated use_media_proxy()/end_media_session() approach. Yes, that is a better way. -- Raúl Alexis Betancor Santana Dimensión Virtual ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Asterisk reinvite confuses Mediaproxy
El Domingo, 12 de Julio de 2009, Iñaki Baz Castillo escribió: > El Sábado, 11 de Julio de 2009, Jeff Pyle escribió: > > Ngrep output is attached. It looks okay to me. > > > > I've indicated which IP addresses belong to which entity at the top of > > the file, and commented who's talking to whom at the # before the packet > > in an attempt to improve readability. > > I don't know a lot about SDP protocol, but shouldn¡t SDP version number > (v=0) be increased in a re-INVITE? Nothe that it's always 0. > Could you try to dissable MediaProxy and check if then the GW and the phone > accept the re-INVITE and send media directly between them? Forget it, "v" is just the SDP protocol version: The "v=" field gives the version of the Session Description Protocol. This memo defines version 0. There is no minor version number. -- Iñaki Baz Castillo ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Asterisk reinvite confuses Mediaproxy
11 jul 2009 kl. 21.02 skrev Iñaki Baz Castillo: > El Sábado, 11 de Julio de 2009, Jeff Pyle escribió: >> Which point(s) would be the most useful to see? Traffic in and out >> of >> Opensips? > > Yes, since It's in the proxy where the SDP is modified. > >> On 7/11/09 2:44 PM, "Iñaki Baz Castillo" wrote: >>> At this point, a SIP trace (ngrep) would be very useful. > On a different note, why keep asterisk re-invites turned on if you use a media proxy in the call? Re-invites are best used when no NAT or firewall support is needed, and since you're using media proxy, it indicates to me that you might not want to have re-invites turned on at all. /O ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Asterisk reinvite confuses Mediaproxy
El Sábado, 11 de Julio de 2009, Jeff Pyle escribió: > Ngrep output is attached. It looks okay to me. > > I've indicated which IP addresses belong to which entity at the top of the > file, and commented who's talking to whom at the # before the packet in an > attempt to improve readability. I don't know a lot about SDP protocol, but shouldn¡t SDP version number (v=0) be increased in a re-INVITE? Nothe that it's always 0. Could you try to dissable MediaProxy and check if then the GW and the phone accept the re-INVITE and send media directly between them? -- Iñaki Baz Castillo ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Asterisk reinvite confuses Mediaproxy
On 7/11/09 5:33 PM, "Raúl Alexis Betancor Santana" wrote: > I will not question why are you trying to use Mediaproxy if not for NAT > fixing .. X-) Because I can. :) Or, rather, I thought I could... Real world applications include more accurate accounting and documenting the codecs in use. For example, if I'm documenting a customer's faxing problem, it is very helpful to know whether it was a G711 or T38 call. I may decide to run it only for clients behind NAT, but if I can reproduce this problem without NAT, why confuse the issue? > For properly handling the re-invite, did you call force_rtp_proxy INSIDE the > in-dialog procces ? force_rtp_proxy() is for rtpproxy; this is Mediaproxy. I'm calling only engage_media_proxy() at the initial INVITE. Perhaps I might have more luck with the less automated use_media_proxy()/end_media_session() approach. I'll try that and see what happens. - Jeff ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Asterisk reinvite confuses Mediaproxy
On Saturday 11 July 2009 22:16:27 you wrote: > Yeah, I suppose so... :) There is no NAT here, however. All public IPs. > The root of the issue isn't NAT fixing, it's that Mediaproxy doesn't seem > to use properly the new information from a reinvite. I will not question why are you trying to use Mediaproxy if not for NAT fixing .. X-) > Failing call flow is: > PSTN Gateway -> Asterisk w/ reinvites -> Opensips -> SIP Phone* > > * Note: "SIP Phone" is really an Asterisk box with a Polycom behind it, > but it's not doing anything screwy. No reinvites from this one. I can > reproduce the same behavior with a Sipura or Polycom registered directly to > Opensips. It's just much harder to test because I don't have any extra > public IPs available in my "home" lab. For properly handling the re-invite, did you call force_rtp_proxy INSIDE the in-dialog procces ? -- Raúl Alexis Betancor Santana Dimensión Virtual ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Asterisk reinvite confuses Mediaproxy
Yeah, I suppose so... :) There is no NAT here, however. All public IPs. The root of the issue isn't NAT fixing, it's that Mediaproxy doesn't seem to use properly the new information from a reinvite. Failing call flow is: PSTN Gateway -> Asterisk w/ reinvites -> Opensips -> SIP Phone* * Note: "SIP Phone" is really an Asterisk box with a Polycom behind it, but it's not doing anything screwy. No reinvites from this one. I can reproduce the same behavior with a Sipura or Polycom registered directly to Opensips. It's just much harder to test because I don't have any extra public IPs available in my "home" lab. - Jeff On 7/11/09 4:52 PM, "Raúl Alexis Betancor Santana" wrote: > If you want to improve readability .. just don't use IP's from a same range in > a capture that is supposed to be about NAT fixing ... ;-) > > After a first read ... your call flow is Asterisk -> OpenSIPS -> Asterisk -> > SIP Phone ? ... or Asterisk -> OpenSIPS -> SIP Phone (beging the same NAT > router as Asterisk) ? > > ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Asterisk reinvite confuses Mediaproxy
On Saturday 11 July 2009 20:18:06 Jeff Pyle wrote: > Ngrep output is attached. It looks okay to me. > > I've indicated which IP addresses belong to which entity at the top of the > file, and commented who's talking to whom at the # before the packet in an > attempt to improve readability. If you want to improve readability .. just don't use IP's from a same range in a capture that is supposed to be about NAT fixing ... ;-) After a first read ... your call flow is Asterisk -> OpenSIPS -> Asterisk -> SIP Phone ? ... or Asterisk -> OpenSIPS -> SIP Phone (beging the same NAT router as Asterisk) ? -- Raúl Alexis Betancor Santana Dimensión Virtual ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Asterisk reinvite confuses Mediaproxy
Ngrep output is attached. It looks okay to me. I've indicated which IP addresses belong to which entity at the top of the file, and commented who's talking to whom at the # before the packet in an attempt to improve readability. - Jeff On 7/11/09 3:02 PM, "Iñaki Baz Castillo" wrote: > Yes, since It's in the proxy where the SDP is modified. opensips.ngrep Description: Binary data ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Asterisk reinvite confuses Mediaproxy
El Sábado, 11 de Julio de 2009, Jeff Pyle escribió: > Which point(s) would be the most useful to see? Traffic in and out of > Opensips? Yes, since It's in the proxy where the SDP is modified. > On 7/11/09 2:44 PM, "Iñaki Baz Castillo" wrote: > > At this point, a SIP trace (ngrep) would be very useful. -- Iñaki Baz Castillo ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Asterisk reinvite confuses Mediaproxy
Which point(s) would be the most useful to see? Traffic in and out of Opensips? On 7/11/09 2:44 PM, "Iñaki Baz Castillo" wrote: > At this point, a SIP trace (ngrep) would be very useful. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Asterisk reinvite confuses Mediaproxy
El Sábado, 11 de Julio de 2009, Jeff Pyle escribió: > Iñaki, > > The PSTN gateway must support in-call reinvites because it sends its RTP to > the Mediaproxy after Asterisk sends its reinvite. Here's a sample of the > RTP from the perspective of the Mediaproxy relay (an obfuscated tshark > output): > > PSTN_gateway -> Mediaproxy UDP src port: 14618 dst port: 16448 >SIP_phone -> Mediaproxy UDP src port: 16892 dst port: 16454 > Mediaproxy ->Asterisk UDP src port: 16452 dst port: 17276 >SIP_phone -> Mediaproxy UDP src port: 16892 dst port: 16454 > Mediaproxy ->Asterisk UDP src port: 16452 dst port: 17276 > PSTN_gateway -> Mediaproxy UDP src port: 14618 dst port: 16452 >SIP_phone -> Mediaproxy UDP src port: 16892 dst port: 16454 > Mediaproxy ->Asterisk UDP src port: 16452 dst port: 17276 > PSTN_gateway -> Mediaproxy UDP src port: 14618 dst port: 16452 >SIP_phone -> Mediaproxy UDP src port: 16892 dst port: 16454 > Mediaproxy ->Asterisk UDP src port: 16452 dst port: 17276 > PSTN_gateway -> Mediaproxy UDP src port: 14618 dst port: 16452 > PSTN_gateway -> Mediaproxy UDP src port: 14618 dst port: 16452 >SIP_phone -> Mediaproxy UDP src port: 16892 dst port: 16454 > Mediaproxy ->Asterisk UDP src port: 16452 dst port: 17276 >SIP_phone -> Mediaproxy UDP src port: 16892 dst port: 16454 > Mediaproxy ->Asterisk UDP src port: 16452 dst port: 17276 > PSTN_gateway -> Mediaproxy UDP src port: 14618 dst port: 16452 >SIP_phone -> Mediaproxy UDP src port: 16892 dst port: 16454 > Mediaproxy ->Asterisk UDP src port: 16452 dst port: 17276 > > Looking at the above capture, we can see that both the PSTN gateway and the > SIP phone are sending their RTP to the Mediaproxy. But, the Mediaproxy > relays the SIP phone's packets to Asterisk, which still has the socket open > to relay them to the PSTN gateway. That's why the SIP phone can be heard > on the PSTN, the but the PSTN phone cannot be heard on the SIP phone. > > The only difference I can see between an inbound call and an outbound call > from a media perspective is that in inbound has no pre-connect media (180 > w/o SDP) while an outbound call has media (183 w/ SDP). MIght that be > relevant? It shouldn't. At this point, a SIP trace (ngrep) would be very useful. -- Iñaki Baz Castillo ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Asterisk reinvite confuses Mediaproxy
Iñaki, The PSTN gateway must support in-call reinvites because it sends its RTP to the Mediaproxy after Asterisk sends its reinvite. Here's a sample of the RTP from the perspective of the Mediaproxy relay (an obfuscated tshark output): PSTN_gateway -> Mediaproxy UDP src port: 14618 dst port: 16448 SIP_phone -> Mediaproxy UDP src port: 16892 dst port: 16454 Mediaproxy ->Asterisk UDP src port: 16452 dst port: 17276 SIP_phone -> Mediaproxy UDP src port: 16892 dst port: 16454 Mediaproxy ->Asterisk UDP src port: 16452 dst port: 17276 PSTN_gateway -> Mediaproxy UDP src port: 14618 dst port: 16452 SIP_phone -> Mediaproxy UDP src port: 16892 dst port: 16454 Mediaproxy ->Asterisk UDP src port: 16452 dst port: 17276 PSTN_gateway -> Mediaproxy UDP src port: 14618 dst port: 16452 SIP_phone -> Mediaproxy UDP src port: 16892 dst port: 16454 Mediaproxy ->Asterisk UDP src port: 16452 dst port: 17276 PSTN_gateway -> Mediaproxy UDP src port: 14618 dst port: 16452 PSTN_gateway -> Mediaproxy UDP src port: 14618 dst port: 16452 SIP_phone -> Mediaproxy UDP src port: 16892 dst port: 16454 Mediaproxy ->Asterisk UDP src port: 16452 dst port: 17276 SIP_phone -> Mediaproxy UDP src port: 16892 dst port: 16454 Mediaproxy ->Asterisk UDP src port: 16452 dst port: 17276 PSTN_gateway -> Mediaproxy UDP src port: 14618 dst port: 16452 SIP_phone -> Mediaproxy UDP src port: 16892 dst port: 16454 Mediaproxy ->Asterisk UDP src port: 16452 dst port: 17276 Looking at the above capture, we can see that both the PSTN gateway and the SIP phone are sending their RTP to the Mediaproxy. But, the Mediaproxy relays the SIP phone's packets to Asterisk, which still has the socket open to relay them to the PSTN gateway. That's why the SIP phone can be heard on the PSTN, the but the PSTN phone cannot be heard on the SIP phone. The only difference I can see between an inbound call and an outbound call from a media perspective is that in inbound has no pre-connect media (180 w/o SDP) while an outbound call has media (183 w/ SDP). MIght that be relevant? - Jeff On 7/11/09 9:09 AM, "Iñaki Baz Castillo" wrote: > Most probably, your PSTN gateway doesn't support/allow media address change > during a call, this is, it doesn't react when Asterisk sends it a re-INVITE > with a new media address in the SDP and the Gw remains using the first SDP. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Asterisk reinvite confuses Mediaproxy
El Sábado, 11 de Julio de 2009, Jeff Pyle escribió: > But, > the PSTN gateway --> SIP Phone audio still relays to Asterisk, Most probably, your PSTN gateway doesn't support/allow media address change during a call, this is, it doesn't react when Asterisk sends it a re-INVITE with a new media address in the SDP and the Gw remains using the first SDP. -- Iñaki Baz Castillo ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
