Re: [OpenSIPS-Users] Ack without To tag
Hello, Please post a trace of this. Best Regards, Vlad Paiu OpenSIPS Developer http://www.opensips-solutions.com On 25.06.2015 06:25, John Nash wrote: Let me add some more details which I noticed. As i explained in previous post in the same subject, we receive ACK without to tag from one UA, since it will not match any dialog, I tried to route it to destination with topology_hiding but topology hiding used different branch tag than the 200 OK received (It only replaced .0 with .2). I think this is happening because I am also using drouting module and UAC which use branches. I can post trace also if someone wants to have a look. On Wed, Jun 24, 2015 at 10:06 PM, John Nash john.nash...@gmail.com mailto:john.nash...@gmail.com wrote: I am using opensips 2.1 with topology_hiding module. I have an issue only with one SIP endpoint. This endpoint sends Ack message (after 200 OK to Invite) without any to tag because of that it is not matching with In dialog request section. Can a UA send ACK without to tag?...If yes any way I can match it with ongoing dialog? John ___ 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] Manually self generate failure
Thanks Jeff, I'll post back how it works for me, and for what use case
I chose what.
On 6/30/15, Jeff Pyle jeff.p...@fidelityvoice.com wrote:
Since the failure route is triggered by tm, I think you have to t_relay()
the request for the failure path to be taken. Maybe you could t_relay() it
to another proxy with custom headers to indicate how you wanted it to fail,
or even t_relay() it to the same proxy with care to handle it as you see
fit.
Or, perhaps this. Let's say you have
route[dostuff] {
stuff();
}
You could make your failure route available to the main script by writing
your failure route like this:
failure_route[failedstuff] {
route[dostuff];
}
So that way a true failure would run the same script as if you were to
manually invoke route[dostuff].
That's a lot of stuff. Hopefully some of it fits your use case.
- Jeff
On Tue, Jun 30, 2015 at 8:14 PM, Podrigal, Aron ar...@guaranteedplus.com
wrote:
Is there a way i can manually make a request fail so that my failure
route
would be invoked? I know this may sound weird, but i encountered some
scenarios that this implementation came to my mind. So i want to know if
this is possible.
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
--
Aron Podrigal
-
//Be happy :-)
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Media-proxy dead air issue
It seems like media proxy flag related issue to me. My guess is from first gateway which fails you get session progress and then it rejects and you get another session progress from second gateway. If you play around with mediaproxy flags (at the time of session progress and 200 OK) it can be solved. On Wed, Jul 1, 2015 at 1:19 AM, pwilli...@turnopen.com wrote: I'm encountering a dead air issue with mediaproxy (version 2.5.2), specifically media-relay application. Seems similar to issue reported by Edwin http://lists.opensips.org/pipermail/users/2015-April/031498.html (no responses) My scenario is that an updated rtp port is sent by my clientSBC after failure of initial gateway, media-relay seems to get the new port via 183, but does not modify the stream correctly. I started media relay with no-fork option and received below. First rtp port negotiated. clientSBC:10568 Updated rtp port requested clientSBC:10570 Expecting this clientSBC:10570 (RTP: clientSBC:10570, RTCP: Unknown) Current Result (old port 10568, still remains) clientSBC:10570 (RTP: clientSBC:10568, RTCP: Unknown) debug: Received new SDP offer mediaproxy.mediacontrol.StreamListenerProtocol starting on 1 mediaproxy.mediacontrol.StreamListenerProtocol starting on 10001 mediaproxy.mediacontrol.StreamListenerProtocol starting on 10002 mediaproxy.mediacontrol.StreamListenerProtocol starting on 10003 debug: Added new stream: (audio) internal-IVR:27980 (RTP: Unknown, RTCP: Unknown) - OpenSIPS:1 - OpenSIPS:10002 - Unknown (RTP: Unknown, RTCP: Unknown) debug: created new session 7cf56d31-8aff-1233-8086-001a4a10fa59: 7185551212@internal-IVR (F366pUF6HNHeg) -- 7325553535@outsideProvider debug: Got traffic information for stream: (audio) internal-IVR:27980 (RTP: Unknown, RTCP: Unknown) - OpenSIPS:1 - OpenSIPS:10002 - Unknown (RTP: clientSBC:10568, RTCP: Unknown) debug: updating existing session 7cf56d31-8aff-1233-8086-001a4a10fa59: 7185551212@internal-IVR (F366pUF6HNHeg) -- 7325553535@outsideProvider debug: Received updated SDP answer debug: Got initial answer from callee for stream: (audio) internal-IVR:27980 (RTP: Unknown, RTCP: Unknown) - OpenSIPS:1 - OpenSIPS:10002 - clientSBC:10570 (RTP: clientSBC:10568, RTCP: Unknown) debug: updating existing session 7cf56d31-8aff-1233-8086-001a4a10fa59: 7185551212@internal-IVR (F366pUF6HNHeg) -- 7325553535@outsideProvider debug: Received updated SDP answer debug: Unchanged stream: (audio) internal-IVR:27980 (RTP: Unknown, RTCP: Unknown) - OpenSIPS:1 - OpenSIPS:10002 - clientSBC:10570 (RTP: clientSBC:10568, RTCP: Unknown) debug: updating existing session 7cf56d31-8aff-1233-8086-001a4a10fa59: 7185551212@internal-IVR (F366pUF6HNHeg) -- 7325553535@outsideProvider debug: Received new SDP offer debug: Found matching existing stream: (audio) internal-IVR:27980 (RTP: Unknown, RTCP: Unknown) - OpenSIPS:1 - OpenSIPS:10002 - clientSBC:10570 (RTP: clientSBC:10568, RTCP: Unknown) debug: updating existing session 7cf56d31-8aff-1233-8086-001a4a10fa59: 7185551212@internal-IVR (F366pUF6HNHeg) -- 7325553535@outsideProvider debug: Received updated SDP answer debug: Unchanged stream: (audio) internal-IVR:27980 (RTP: Unknown, RTCP: Unknown) - OpenSIPS:1 - OpenSIPS:10002 - clientSBC:10570 (RTP: clientSBC:10568, RTCP: Unknown) debug: Got traffic information for stream: (audio) internal-IVR:27980 (RTP: internal-IVR:27980, RTCP: Unknown) - OpenSIPS:1 - OpenSIPS:10002 - clientSBC:10570 (RTP: clientSBC:10568, RTCP: Unknown) debug: removing session 7cf56d31-8aff-1233-8086-001a4a10fa59: 7185551212@internal-IVR (F366pUF6HNHeg) -- 7325553535@outsideProvider (Port 1 Closed) (Port 10001 Closed) (Port 10002 Closed) (Port 10003 Closed) Seems like a bug. Anyone experienced this before... is there a fix.. If no fix, anyone familiar enough with the codebase to point out how to update the port object/attribute for the stream? I'm troubleshooting/modifying code on my own, but wanted to cover all bases. Thanks, Paul W. ___ 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
[OpenSIPS-Users] Manually self generate failure
Is there a way i can manually make a request fail so that my failure route would be invoked? I know this may sound weird, but i encountered some scenarios that this implementation came to my mind. So i want to know if this is possible. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Manually self generate failure
Since the failure route is triggered by tm, I think you have to t_relay()
the request for the failure path to be taken. Maybe you could t_relay() it
to another proxy with custom headers to indicate how you wanted it to fail,
or even t_relay() it to the same proxy with care to handle it as you see
fit.
Or, perhaps this. Let's say you have
route[dostuff] {
stuff();
}
You could make your failure route available to the main script by writing
your failure route like this:
failure_route[failedstuff] {
route[dostuff];
}
So that way a true failure would run the same script as if you were to
manually invoke route[dostuff].
That's a lot of stuff. Hopefully some of it fits your use case.
- Jeff
On Tue, Jun 30, 2015 at 8:14 PM, Podrigal, Aron ar...@guaranteedplus.com
wrote:
Is there a way i can manually make a request fail so that my failure route
would be invoked? I know this may sound weird, but i encountered some
scenarios that this implementation came to my mind. So i want to know if
this is possible.
___
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] Ack without To tag
I think you mean the SIP messages exchanged. If any more info needed i can send. 1.1.1.1 == UA 2.2.2.2 == Opensips == number dialed 1.1.1.1 === 2.2.2.2 INVITE sip:@2.2.2.2:9092;transport=udp SIP/2.0 Via: SIP/2.0/UDP 1.1.1.1:60704;rport;branch=z9hG4bKac2a2c3c77b3c043ad3d85118 Max-Forwards: 70 From: sip:5656@2.2.2.2;tag=f2e3a2e6ed6a6f4399443d7e0347f20d To: sip:@2.2.2.2 Contact: sip:5656@1.1.1.1:60704 Call-ID: b94573d6d94ee54ca945310968a14065 CSeq: 3 INVITE User-Agent: Softphone Dialer v 4.02 Allow: INVITE, ACK, CANCEL, BYE, OPTIONS Content-Type: application/sdp Content-Length: 181 v=0 o=- 1435147412 1435147412 IN IP4 1.1.1.1 s= Media Server c=IN IP4 1.1.1.1 t=0 0 m=audio 60705 RTP/AVP 18 a=rtpmap:18 G729/8000 a=ptime:20 a=fmtp:18 annexb=no 2.2.2.2 === 1.1.1.1 SIP/2.0 407 Proxy Authentication Required Via: SIP/2.0/UDP 1.1.1.1:60704 ;received=1.1.1.1;rport=60704;branch=z9hG4bKac2a2c3c77b3c043ad3d85118 From: sip:5656@2.2.2.2;tag=f2e3a2e6ed6a6f4399443d7e0347f20d To: sip:@2.2.2.2;tag=aabd1841c260dd885edee5bb6208511c.bd84 Call-ID: b94573d6d94ee54ca945310968a14065 CSeq: 3 INVITE Proxy-Authenticate: Digest realm=2.2.2.2, nonce=558a9cb60113aa59d19d1ae0ae586b08ead15a79cc44 Server: opensips Proxy v4.20 Content-Length: 0 2.2.2.2 === 1.1.1.1 ACK sip:2.2.2.2:9092;transport=udp SIP/2.0 Via: SIP/2.0/UDP 1.1.1.1:60704;rport;branch=z9hG4bKac2a2c3c77b3c043ad3d85118 Max-Forwards: 70 From: sip:5656@2.2.2.2;tag=f2e3a2e6ed6a6f4399443d7e0347f20d To: sip:@2.2.2.2 Call-ID: b94573d6d94ee54ca945310968a14065 CSeq: 3 ACK Content-Length: 0 1.1.1.1 === 2.2.2.2 INVITE sip:@2.2.2.2:9092;transport=udp SIP/2.0 Via: SIP/2.0/UDP 1.1.1.1:60704;rport;branch=z9hG4bK43d3de0414c6ba469c30a9d43 Max-Forwards: 70 From: sip:5656@2.2.2.2;tag=f2e3a2e6ed6a6f4399443d7e0347f20d To: sip:@2.2.2.2 Contact: sip:5656@1.1.1.1:60704 Call-ID: b94573d6d94ee54ca945310968a14065 CSeq: 4 INVITE User-Agent: Softphone Dialer v 4.02 Proxy-Authorization: DIGEST username=5656, realm=2.2.2.2, nonce=558a9cb60113aa59d19d1ae0ae586b08ead15a79cc44, uri= sip:@2.2.2.2, response=a2741b5fd118bac802d467a7d405f4c4 Allow: INVITE, ACK, CANCEL, BYE, OPTIONS Content-Type: application/sdp Content-Length: 181 v=0 o=- 1435147412 1435147412 IN IP4 1.1.1.1 s= Media Server c=IN IP4 1.1.1.1 t=0 0 m=audio 60705 RTP/AVP 18 a=rtpmap:18 G729/8000 a=ptime:20 a=fmtp:18 annexb=no 2.2.2.2 === 1.1.1.1 SIP/2.0 100 Giving a try Via: SIP/2.0/UDP 1.1.1.1:60704 ;received=1.1.1.1;rport=60704;branch=z9hG4bK43d3de0414c6ba469c30a9d43 From: sip:5656@2.2.2.2;tag=f2e3a2e6ed6a6f4399443d7e0347f20d To: sip:@2.2.2.2 Call-ID: b94573d6d94ee54ca945310968a14065 CSeq: 4 INVITE Server: opensips Proxy v4.20 Content-Length: 0 2.2.2.2 === 1.1.1.1 SIP/2.0 183 Session Progress Via: SIP/2.0/UDP 1.1.1.1:60704 ;received=1.1.1.1;rport=60704;branch=z9hG4bK43d3de0414c6ba469c30a9d43 From: sip:5656@2.2.2.2;tag=f2e3a2e6ed6a6f4399443d7e0347f20d To: sip:@2.2.2.2;tag=r8HZU2gDavryg Call-ID: b94573d6d94ee54ca945310968a14065 CSeq: 4 INVITE Contact: sip:@2.2.2.2:9092;did=499.a0c0dd53 Accept: application/sdp Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE Supported: timer, path, replaces Content-Type: application/sdp Content-Disposition: session Content-Length: 215 User-Agent: Bridge v4.20 v=0 o=FreeSWITCH 1435123396 1435123397 IN IP4 2.2.2.2 s=FreeSWITCH c=IN IP4 2.2.2.2 t=0 0 m=audio 18344 RTP/AVP 18 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=ptime:20 a=sendrecv a=rtcp:18345 2.2.2.2 === 1.1.1.1 SIP/2.0 200 OK Via: SIP/2.0/UDP 1.1.1.1:60704 ;received=1.1.1.1;rport=60704;branch=z9hG4bK43d3de0414c6ba469c30a9d43 From: sip:5656@2.2.2.2;tag=f2e3a2e6ed6a6f4399443d7e0347f20d To: sip:@2.2.2.2;tag=r8HZU2gDavryg Call-ID: b94573d6d94ee54ca945310968a14065 CSeq: 4 INVITE Contact: sip:@2.2.2.2:9092;did=499.a0c0dd53 Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE Supported: timer, path, replaces Content-Type: application/sdp Content-Length: 212 User-Agent: Bridge v4.20 v=0 o=FreeSWITCH 1108548551 190529 IN IP4 2.2.2.2 s=FreeSWITCH c=IN IP4 2.2.2.2 t=0 0 m=audio 18364 RTP/AVP 18 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=maxptime:20 a=sendrecv a=rtcp:18365 1.1.1.1 === 2.2.2.2 ACK sip:2.2.2.2:9092;transport=udp SIP/2.0 Via: SIP/2.0/UDP 1.1.1.1:60704;rport;branch=z9hG4bK43d3de0414c6ba469c30a9d43 Max-Forwards: 70 From: sip:5656@2.2.2.2;tag=f2e3a2e6ed6a6f4399443d7e0347f20d To: sip:@2.2.2.2 Call-ID: b94573d6d94ee54ca945310968a14065 CSeq: 4 ACK Content-Length: 0 After that 200 OK is sent to 1.1.1.1 again and again and it sends ACK On Tue, Jun 30, 2015 at 1:36 PM, Vlad Paiu vladp...@opensips.org wrote: Hello, Please post a trace of this. Best
[OpenSIPS-Users] send_reply vs t_reply
I would like to get some details on the difference if one uses send_reply or t_reply for a sip message. Is there any major differences where the reply sent from, and what function is used? Thank you. -- Aron Podrigal - //Be happy :-) ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] NAT problem
Hi,
Thanks for the reply.
Manually insert header field Record-Route by
insert_hf(Record-Route: sip:106.x.x.x\r\n);
And, change IP in SDP
if (has_body(application/sdp)) {
replace_all(IN IP4 [0-9]\.[0-9]\.[0-9]\.[0-9], 106.x.x.x);
}
Seems work with WIFI behind one level NAT, not test 3G/4G.
--
xiaofeng
--
gpg key fingerprint:
2048R/5E63005B
C84F 671F 70B7 7330 4726 5EC8 02BC CBA2 5E63 005B
Distribution: Fedora 17 (Beefy Miracle)
Fedora Project https://fedoraproject.org/
--
trans-zh_cn mailing list
trans-zh...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/trans-zh_cn
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Media-proxy dead air issue
I'm encountering a dead air issue with mediaproxy (version 2.5.2), specifically media-relay application. Seems similar to issue reported by Edwin http://lists.opensips.org/pipermail/users/2015-April/031498.html (no responses)My scenario is that an updated rtp port is sent by my clientSBC after failure of initial gateway, media-relay seems to get the new port via 183, but does not modify the stream correctly.I started media relay with no-fork option and received below. First rtp port negotiated.clientSBC:10568Updated rtp port requestedclientSBC:10570Expecting this clientSBC:10570 (RTP: clientSBC:10570, RTCP: Unknown)Current Result (old port 10568, still remains) clientSBC:10570 (RTP: clientSBC:10568, RTCP: Unknown)debug: Received new SDP offermediaproxy.mediacontrol.StreamListenerProtocol starting on 1mediaproxy.mediacontrol.StreamListenerProtocol starting on 10001mediaproxy.mediacontrol.StreamListenerProtocol starting on 10002mediaproxy.mediacontrol.StreamListenerProtocol starting on 10003debug: Added new stream: (audio) internal-IVR:27980 (RTP: Unknown, RTCP: Unknown) - OpenSIPS:1 - OpenSIPS:10002 - Unknown (RTP: Unknown, RTCP: Unknown)debug: created new session 7cf56d31-8aff-1233-8086-001a4a10fa59: 7185551212@internal-IVR (F366pUF6HNHeg) -- 7325553535@outsideProviderdebug: Got traffic information for stream: (audio) internal-IVR:27980 (RTP: Unknown, RTCP: Unknown) - OpenSIPS:1 - OpenSIPS:10002 - Unknown (RTP: clientSBC:10568, RTCP: Unknown)debug: updating existing session 7cf56d31-8aff-1233-8086-001a4a10fa59: 7185551212@internal-IVR (F366pUF6HNHeg) -- 7325553535@outsideProviderdebug: Received updated SDP answerdebug: Got initial answer from callee for stream: (audio) internal-IVR:27980 (RTP: Unknown, RTCP: Unknown) - OpenSIPS:1 - OpenSIPS:10002 - clientSBC:10570 (RTP: clientSBC:10568, RTCP: Unknown)debug: updating existing session 7cf56d31-8aff-1233-8086-001a4a10fa59: 7185551212@internal-IVR (F366pUF6HNHeg) -- 7325553535@outsideProviderdebug: Received updated SDP answerdebug: Unchanged stream: (audio) internal-IVR:27980 (RTP: Unknown, RTCP: Unknown) - OpenSIPS:1 - OpenSIPS:10002 - clientSBC:10570 (RTP: clientSBC:10568, RTCP: Unknown)debug: updating existing session 7cf56d31-8aff-1233-8086-001a4a10fa59: 7185551212@internal-IVR (F366pUF6HNHeg) -- 7325553535@outsideProviderdebug: Received new SDP offerdebug: Found matching existing stream: (audio) internal-IVR:27980 (RTP: Unknown, RTCP: Unknown) - OpenSIPS:1 - OpenSIPS:10002 - clientSBC:10570 (RTP: clientSBC:10568, RTCP: Unknown)debug: updating existing session 7cf56d31-8aff-1233-8086-001a4a10fa59: 7185551212@internal-IVR (F366pUF6HNHeg) -- 7325553535@outsideProviderdebug: Received updated SDP answerdebug: Unchanged stream: (audio) internal-IVR:27980 (RTP: Unknown, RTCP: Unknown) - OpenSIPS:1 - OpenSIPS:10002 - clientSBC:10570 (RTP: clientSBC:10568, RTCP: Unknown)debug: Got traffic information for stream: (audio) internal-IVR:27980 (RTP: internal-IVR:27980, RTCP: Unknown) - OpenSIPS:1 - OpenSIPS:10002 - clientSBC:10570 (RTP: clientSBC:10568, RTCP: Unknown)debug: removing session 7cf56d31-8aff-1233-8086-001a4a10fa59: 7185551212@internal-IVR (F366pUF6HNHeg) -- 7325553535@outsideProvider(Port 1 Closed)(Port 10001 Closed)(Port 10002 Closed)(Port 10003 Closed)Seems like a bug.Anyone experienced this before... is there a fix..If no fix, anyone familiar enough with the codebase to point out how to update the port object/attribute for the stream?I'm troubleshooting/modifying code on my own, but wanted to cover all bases.Thanks,Paul W. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Media-proxy dead air issue (Plain text)
I'm encountering a dead air issue with mediaproxy (version 2.5.2), specifically media-relay application. Seems similar to issue reported by Edwin http://lists.opensips.org/pipermail/users/2015-April/031498.html (no responses) My scenario is that an updated rtp port is sent by my clientSBC after failure of initial gateway, media-relay seems to get the new port via 183, but does not modify the stream correctly. I started media relay with no-fork option and received below. First rtp port negotiated. clientSBC:10568 Updated rtp port requested clientSBC:10570 Expecting this clientSBC:10570 (RTP: clientSBC:10570, RTCP: Unknown) Current Result (old port 10568, still remains) clientSBC:10570 (RTP: clientSBC:10568, RTCP: Unknown) debug: Received new SDP offer mediaproxy.mediacontrol.StreamListenerProtocol starting on 1 mediaproxy.mediacontrol.StreamListenerProtocol starting on 10001 mediaproxy.mediacontrol.StreamListenerProtocol starting on 10002 mediaproxy.mediacontrol.StreamListenerProtocol starting on 10003 debug: Added new stream: (audio) internal-IVR:27980 (RTP: Unknown, RTCP: Unknown) - OpenSIPS:1 - OpenSIPS:10002 - Unknown (RTP: Unknown, RTCP: Unknown) debug: created new session 7cf56d31-8aff-1233-8086-001a4a10fa59: 7185551212@internal-IVR (F366pUF6HNHeg) -- 7325553535@outsideProvider debug: Got traffic information for stream: (audio) internal-IVR:27980 (RTP: Unknown, RTCP: Unknown) - OpenSIPS:1 - OpenSIPS:10002 - Unknown (RTP: clientSBC:10568, RTCP: Unknown) debug: updating existing session 7cf56d31-8aff-1233-8086-001a4a10fa59: 7185551212@internal-IVR (F366pUF6HNHeg) -- 7325553535@outsideProvider debug: Received updated SDP answer debug: Got initial answer from callee for stream: (audio) internal-IVR:27980 (RTP: Unknown, RTCP: Unknown) - OpenSIPS:1 - OpenSIPS:10002 - clientSBC:10570 (RTP: clientSBC:10568, RTCP: Unknown) debug: updating existing session 7cf56d31-8aff-1233-8086-001a4a10fa59: 7185551212@internal-IVR (F366pUF6HNHeg) -- 7325553535@outsideProvider debug: Received updated SDP answer debug: Unchanged stream: (audio) internal-IVR:27980 (RTP: Unknown, RTCP: Unknown) - OpenSIPS:1 - OpenSIPS:10002 - clientSBC:10570 (RTP: clientSBC:10568, RTCP: Unknown) debug: updating existing session 7cf56d31-8aff-1233-8086-001a4a10fa59: 7185551212@internal-IVR (F366pUF6HNHeg) -- 7325553535@outsideProvider debug: Received new SDP offer debug: Found matching existing stream: (audio) internal-IVR:27980 (RTP: Unknown, RTCP: Unknown) - OpenSIPS:1 - OpenSIPS:10002 - clientSBC:10570 (RTP: clientSBC:10568, RTCP: Unknown) debug: updating existing session 7cf56d31-8aff-1233-8086-001a4a10fa59: 7185551212@internal-IVR (F366pUF6HNHeg) -- 7325553535@outsideProvider debug: Received updated SDP answer debug: Unchanged stream: (audio) internal-IVR:27980 (RTP: Unknown, RTCP: Unknown) - OpenSIPS:1 - OpenSIPS:10002 - clientSBC:10570 (RTP: clientSBC:10568, RTCP: Unknown) debug: Got traffic information for stream: (audio) internal-IVR:27980 (RTP: internal-IVR:27980, RTCP: Unknown) - OpenSIPS:1 - OpenSIPS:10002 - clientSBC:10570 (RTP: clientSBC:10568, RTCP: Unknown) debug: removing session 7cf56d31-8aff-1233-8086-001a4a10fa59: 7185551212@internal-IVR (F366pUF6HNHeg) -- 7325553535@outsideProvider (Port 1 Closed) (Port 10001 Closed) (Port 10002 Closed) (Port 10003 Closed) Seems like a bug. Anyone experienced this before... is there a fix.. If no fix, anyone familiar enough with the codebase to point out how to update the port object/attribute for the stream? I'm troubleshooting/modifying code on my own, but wanted to cover all bases. Thanks, Paul W. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
