Re: [OpenSIPS-Users] Getting header from 302

[Jeff Pyle]

I've been working on a proxy to sit between MS Teams and "normal" SIP
stacks.  Teams sends way too many 180s and RTP-less 183s so I sanitize them
like this:

onreply_route[relay_reply] {
if (t_check_status("180")) {
if (isflagset("GOT_180")) {
drop;
} else {
setflag("GOT_180");
}
}

if (isflagset("GOT_180") && t_check_status("183")) {
drop;
}
}

With this I stop superfluous 18x messages from being relayed downstream.
The 'drop' here kills the message completely.  You could include the drop
if you want to stop the message from being relayed (which you probably do)
and are finished processing it in the script (which you are probably not).

If I understand your application correctly, I'd populate the AVP in the
reply route and do everything else in the failure route.  Or, try Liviu's
suggestion of using $(hdr(Identity)) in the failure_route directly.
Either way, then continue in the failure_route to do whatever else needs to
happen.


- Jeff



On Wed, Jun 2, 2021 at 2:10 PM David Villasmil <
david.villasmil.w...@gmail.com> wrote:

> Hello Jeff,
>
> That's exactly what I'm doing:
>
> # Relay to REDIRECT server
> route[relay_to_REDIRECT]
> {
> t_on_reply("reply_from_REDIRECT");
> t_on_failure("failure_from_REDIRECT");
>
> xlog("L_ERR", "[$ci][$rm]: Relaying to REDIRECT");
> if (!t_relay()) {
> xlog("L_ERR", "[$ci][$rm]: unable to relay request $ru to $tU --
> replying with error");
> sl_reply_error();
> }
>
> exit;
> }
>
> # Response from REDIRECT will come in here.
> failure_route[failure_from_REDIRECT]
> {
> xlog("L_ERR", "[$ci][$rm]: I'm in
> failure_route[failover_from_REDIRECT]");
> if (t_was_cancelled()) {
> exit;
> }
>
> if(is_avp_set("$avp(myheader)")) {
> xlog("L_ERR", "[$ci][$rm]: Got Identity Header: $(hdr(myheader))");
> setflag(100);
> route(invite);
> }
> }
>
> # Response 302 from REDIRECT will come in here.
> onreply_route[reply_from_REDIRECT]
> {
> xlog("L_ERR", "[$ci][$rm]: I'm in onreply_route[reply_from_REDIRECT]");
> if (t_was_cancelled()) {
> exit;
> }
>
> # detect redirect, store the header and send to "invite" as normally
> if (t_check_status("302") && is_present_hf("myheader")) {
> $avp(identity_header) = $(hdr(myheader));
> setflag(100);
> drop();
> }
> }
>
> So I suppose i don't need the drop()?
>
> Regards,
>
> David Villasmil
> email: david.villasmil.w...@gmail.com
> phone: +34669448337
>
>
> On Wed, Jun 2, 2021 at 4:32 PM Jeff Pyle  wrote:
>
>> If I arm both t_on_failure() and t_on_reply(), do a t_relay(), and a 302
>> comes back, I have access to the reply in the onreply_route, then the
>> failure_route.  From a SIP perspective, a 302 is a failure since it's not
>> 2xx-series, no?  I don't do a drop() in the onreply_route.  It just
>> naturally follows its course to the failure_route.
>>
>> David, in your case, since you're trying to drop any 302 that doesn't
>> have an Identity header, I'd check for its presence in the onreply_route
>> and set a flag if there accordingly.  And, capture its value in an AVP if
>> you need.  Next, in the failure_route, if (t_check_status("302") &&
>> !isflagset("302_HAS_ID_HEADER")) drop; or something similar.  You could
>> easily expand that block to route-advance to your next carrier,
>> send_reply(499, "Something Else"), or whatever you makes sense for your
>> application.
>>
>>
>> - Jeff
>>
>> On Wed, Jun 2, 2021 at 10:19 AM Johan De Clercq  wrote:
>>
>>> that's because 302 is not an error.
>>> So I guess that drop() is the only way.
>>>
>>> Op wo 2 jun. 2021 om 15:42 schreef David Villasmil <
>>> david.villasmil.w...@gmail.com>:
>>>
 Thanks Ben,

 That’s a good point. But only way I’ve found to jump over from oneply
 to failure_route is by doing a drop(). If there’s another way, I’d love to
 know about it!

 David

 On Wed, 2 Jun 2021 at 08:29, Ben Newlin  wrote:

> You still don’t need to call drop() as long as you are handling the
> request in failure_route. The 302 will not be sent back upstream as long 
> as
> failure_route either creates a new branch request or sends back a 
> different
> reply code. Only if failure_route exits without doing either of these
> things would the downstream 302 be sent back upstream as-is.
>
>
>
> In fact, as far as I know drop() has no functionality for responses >=
> 200.
>
>
>
> Ben Newlin
>
>
> ___
>> 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] Getting header from 302

[David Villasmil]

Hello Jeff,

That's exactly what I'm doing:

# Relay to REDIRECT server
route[relay_to_REDIRECT]
{
t_on_reply("reply_from_REDIRECT");
t_on_failure("failure_from_REDIRECT");

xlog("L_ERR", "[$ci][$rm]: Relaying to REDIRECT");
if (!t_relay()) {
xlog("L_ERR", "[$ci][$rm]: unable to relay request $ru to $tU --
replying with error");
sl_reply_error();
}

exit;
}

# Response from REDIRECT will come in here.
failure_route[failure_from_REDIRECT]
{
xlog("L_ERR", "[$ci][$rm]: I'm in
failure_route[failover_from_REDIRECT]");
if (t_was_cancelled()) {
exit;
}

if(is_avp_set("$avp(myheader)")) {
xlog("L_ERR", "[$ci][$rm]: Got Identity Header: $(hdr(myheader))");
setflag(100);
route(invite);
}
}

# Response 302 from REDIRECT will come in here.
onreply_route[reply_from_REDIRECT]
{
xlog("L_ERR", "[$ci][$rm]: I'm in onreply_route[reply_from_REDIRECT]");
if (t_was_cancelled()) {
exit;
}

# detect redirect, store the header and send to "invite" as normally
if (t_check_status("302") && is_present_hf("myheader")) {
$avp(identity_header) = $(hdr(myheader));
setflag(100);
drop();
}
}

So I suppose i don't need the drop()?

Regards,

David Villasmil
email: david.villasmil.w...@gmail.com
phone: +34669448337


On Wed, Jun 2, 2021 at 4:32 PM Jeff Pyle  wrote:

> If I arm both t_on_failure() and t_on_reply(), do a t_relay(), and a 302
> comes back, I have access to the reply in the onreply_route, then the
> failure_route.  From a SIP perspective, a 302 is a failure since it's not
> 2xx-series, no?  I don't do a drop() in the onreply_route.  It just
> naturally follows its course to the failure_route.
>
> David, in your case, since you're trying to drop any 302 that doesn't have
> an Identity header, I'd check for its presence in the onreply_route and set
> a flag if there accordingly.  And, capture its value in an AVP if you
> need.  Next, in the failure_route, if (t_check_status("302") &&
> !isflagset("302_HAS_ID_HEADER")) drop; or something similar.  You could
> easily expand that block to route-advance to your next carrier,
> send_reply(499, "Something Else"), or whatever you makes sense for your
> application.
>
>
> - Jeff
>
> On Wed, Jun 2, 2021 at 10:19 AM Johan De Clercq  wrote:
>
>> that's because 302 is not an error.
>> So I guess that drop() is the only way.
>>
>> Op wo 2 jun. 2021 om 15:42 schreef David Villasmil <
>> david.villasmil.w...@gmail.com>:
>>
>>> Thanks Ben,
>>>
>>> That’s a good point. But only way I’ve found to jump over from oneply to
>>> failure_route is by doing a drop(). If there’s another way, I’d love to
>>> know about it!
>>>
>>> David
>>>
>>> On Wed, 2 Jun 2021 at 08:29, Ben Newlin  wrote:
>>>
 You still don’t need to call drop() as long as you are handling the
 request in failure_route. The 302 will not be sent back upstream as long as
 failure_route either creates a new branch request or sends back a different
 reply code. Only if failure_route exits without doing either of these
 things would the downstream 302 be sent back upstream as-is.



 In fact, as far as I know drop() has no functionality for responses >=
 200.



 Ben Newlin


 ___
> 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] Getting header from 302

[Liviu Chircu]

On 02.06.2021 18:31, Jeff Pyle wrote:

if (t_check_status("302") && !isflagset("302_HAS_ID_HEADER"))


Glancing over this flag-based code snippet, I just want to make sure 
Ben's earlier suggestion was not missed:


Did you try accessing the Identity header within the failure_route, but 
using the $(hdr(Identity)) construct?  And did it work as 
expected or not?


--
Liviu Chircu
www.twitter.com/liviuchircu | www.opensips-solutions.com
OpenSIPS Summit 2021 Distributed | www.opensips.org/events


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Getting header from 302

[Jeff Pyle]

If I arm both t_on_failure() and t_on_reply(), do a t_relay(), and a 302
comes back, I have access to the reply in the onreply_route, then the
failure_route.  From a SIP perspective, a 302 is a failure since it's not
2xx-series, no?  I don't do a drop() in the onreply_route.  It just
naturally follows its course to the failure_route.

David, in your case, since you're trying to drop any 302 that doesn't have
an Identity header, I'd check for its presence in the onreply_route and set
a flag if there accordingly.  And, capture its value in an AVP if you
need.  Next, in the failure_route, if (t_check_status("302") &&
!isflagset("302_HAS_ID_HEADER")) drop; or something similar.  You could
easily expand that block to route-advance to your next carrier,
send_reply(499, "Something Else"), or whatever you makes sense for your
application.


- Jeff

On Wed, Jun 2, 2021 at 10:19 AM Johan De Clercq  wrote:

> that's because 302 is not an error.
> So I guess that drop() is the only way.
>
> Op wo 2 jun. 2021 om 15:42 schreef David Villasmil <
> david.villasmil.w...@gmail.com>:
>
>> Thanks Ben,
>>
>> That’s a good point. But only way I’ve found to jump over from oneply to
>> failure_route is by doing a drop(). If there’s another way, I’d love to
>> know about it!
>>
>> David
>>
>> On Wed, 2 Jun 2021 at 08:29, Ben Newlin  wrote:
>>
>>> You still don’t need to call drop() as long as you are handling the
>>> request in failure_route. The 302 will not be sent back upstream as long as
>>> failure_route either creates a new branch request or sends back a different
>>> reply code. Only if failure_route exits without doing either of these
>>> things would the downstream 302 be sent back upstream as-is.
>>>
>>>
>>>
>>> In fact, as far as I know drop() has no functionality for responses >=
>>> 200.
>>>
>>>
>>>
>>> Ben Newlin
>>>
>>>
>>>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Getting header from 302

[Johan De Clercq]

that's because 302 is not an error.
So I guess that drop() is the only way.

Op wo 2 jun. 2021 om 15:42 schreef David Villasmil <
david.villasmil.w...@gmail.com>:

> Thanks Ben,
>
> That’s a good point. But only way I’ve found to jump over from oneply to
> failure_route is by doing a drop(). If there’s another way, I’d love to
> know about it!
>
> David
>
> On Wed, 2 Jun 2021 at 08:29, Ben Newlin  wrote:
>
>> You still don’t need to call drop() as long as you are handling the
>> request in failure_route. The 302 will not be sent back upstream as long as
>> failure_route either creates a new branch request or sends back a different
>> reply code. Only if failure_route exits without doing either of these
>> things would the downstream 302 be sent back upstream as-is.
>>
>>
>>
>> In fact, as far as I know drop() has no functionality for responses >=
>> 200.
>>
>>
>>
>> Ben Newlin
>>
>>
>>
>> *From: *Users  on behalf of Jeff Pyle <
>> j...@ugnd.org>
>> *Date: *Tuesday, June 1, 2021 at 2:48 PM
>> *To: *OpenSIPS users mailling list 
>> *Subject: *Re: [OpenSIPS-Users] Getting header from 302
>>
>> Oh!  Understood.
>>
>>
>>
>>
>>
>> - Jeff
>>
>>
>>
>>
>>
>> On Tue, Jun 1, 2021 at 2:42 PM David Villasmil <
>> david.villasmil.w...@gmail.com> wrote:
>>
>> The thing is I _want_ to drop the 302, I don't want to do anything else
>> with it.
>>
>>
>> Regards,
>>
>>
>>
>> David Villasmil
>>
>> email: david.villasmil.w...@gmail.com
>>
>> phone: +34669448337
>>
>>
>>
>>
>>
>> On Tue, Jun 1, 2021 at 6:46 PM Jeff Pyle  wrote:
>>
>> In my experience you don't need drop() in the reply route.  Just store
>> the AVP and move on.  Something like this:
>>
>>
>>
>> onreply_route[collect_identity] {
>>
>> if (is_present_hf("Identity")) {
>>
>> $avp(identity) := $hdr(Identity);
>>
>> setflag("GOT_IDENTITY");
>>
>> }
>>
>> }
>>
>>
>>
>> If you've armed both the reply and failure routes with t_on_reply() and
>> t_on_failure(), the $avp(identity) variable set here will be available in
>> the failure_route.  The GOT_IDENTITY flag, too.
>>
>>
>>
>>
>>
>> - Jeff
>>
>>
>>
>>
>>
>>
>>
>> - Jeff
>>
>>
>>
>>
>>
>> On Tue, Jun 1, 2021 at 11:20 AM David Villasmil <
>> david.villasmil.w...@gmail.com> wrote:
>>
>> Yes, I see it is documented.
>>
>>
>>
>> So the reply header is only availanble on the "onreply" route, not on the
>> "failure" route. That was my problem. I do indeed use an avp to store the
>> header.
>>
>> I ended up getting the header on the "onreply" and storing it in an avp,
>> set a flag and then drop(). I noticed the "failure" route is then executed.
>>
>> From there I can send the processing to the invite route and by  checking
>> the flag, adding the header from the avp.
>>
>>
>>
>> Thanks for your help!
>>
>>
>> Regards,
>>
>>
>>
>> David Villasmil
>>
>> email: david.villasmil.w...@gmail.com
>>
>> phone: +34669448337
>>
>>
>>
>>
>>
>> On Tue, Jun 1, 2021 at 3:52 PM Ben Newlin  wrote:
>>
>> It’s documented that it works this way. The message being processed in
>> failure_route is the original request; in reply_route it’s the reply. [1]
>>
>>
>>
>> You can use variable context to access the reply from failure_route [2].
>> Another option would be to extract the header value into and AVP in
>> reply_route and then reference the AVP from failure_route.
>>
>>
>>
>>
>>
>> [1] - https://www.opensips.org/Documentation/Script-Routes-3-2
>>
>> [2] - https://www.opensips.org/Documentation/Script-CoreVar-3-2
>>
>>
>>
>> Ben Newlin
>>
>>
>>
>> *From: *Users  on behalf of David
>> Villasmil 
>> *Date: *Tuesday, June 1, 2021 at 10:43 AM
>> *To: *OpenSIPS users mailling list 
>> *Subject: *Re: [OpenSIPS-Users] Getting header from 302
>>
>> Yeah, my thing is when i use the failure route i can in theory grab the
>> response header and ignore the 302 and send to the invite route again to
>> actually send the call out via do_routing.
>>
>> What I'm trying to do is:
>>
>> - On receiving an invite: forward to an endpoint.
>>
>> - This endpoint will simply reply with 302 including a header.
>>
>> - I want to grab that header and continue routing normally (do_routing)
>>
>>
>>
>> I could do that with the failure route, but not so sure about the onreply
>> route.
>>
>>
>> Regards,
>>
>>
>>
>> David Villasmil
>>
>> email: david.villasmil.w...@gmail.com
>>
>> phone: +34669448337
>>
>>
>>
>>
>>
>> On Tue, Jun 1, 2021 at 2:34 PM Jeff Pyle  wrote:
>>
>> I don't think you're doing anything wrong.  I think I found the same
>> thing, that headers on the reply were available only in a reply route and
>> not in a failure route.  If you know where to look for them to populate the
>> AVP, I suppose it doesn't matter much.
>>
>>
>>
>> I haven't looked at the code but I suspect all the routes other than an
>> onreply_route give you access to the requests headers, and onreply_route
>> gives you access to the reply headers.  Makes sense I guess.
>>
>>
>>
>>
>>
>> - Jeff
>>
>>
>>
>>
>>
>> On Tue, Jun 1, 2021 at 9:31 AM David Villasmil <
>> david

Re: [OpenSIPS-Users] Getting header from 302

[David Villasmil]

Thanks Ben,

That’s a good point. But only way I’ve found to jump over from oneply to
failure_route is by doing a drop(). If there’s another way, I’d love to
know about it!

David

On Wed, 2 Jun 2021 at 08:29, Ben Newlin  wrote:

> You still don’t need to call drop() as long as you are handling the
> request in failure_route. The 302 will not be sent back upstream as long as
> failure_route either creates a new branch request or sends back a different
> reply code. Only if failure_route exits without doing either of these
> things would the downstream 302 be sent back upstream as-is.
>
>
>
> In fact, as far as I know drop() has no functionality for responses >= 200.
>
>
>
> Ben Newlin
>
>
>
> *From: *Users  on behalf of Jeff Pyle <
> j...@ugnd.org>
> *Date: *Tuesday, June 1, 2021 at 2:48 PM
> *To: *OpenSIPS users mailling list 
> *Subject: *Re: [OpenSIPS-Users] Getting header from 302
>
> Oh!  Understood.
>
>
>
>
>
> - Jeff
>
>
>
>
>
> On Tue, Jun 1, 2021 at 2:42 PM David Villasmil <
> david.villasmil.w...@gmail.com> wrote:
>
> The thing is I _want_ to drop the 302, I don't want to do anything else
> with it.
>
>
> Regards,
>
>
>
> David Villasmil
>
> email: david.villasmil.w...@gmail.com
>
> phone: +34669448337
>
>
>
>
>
> On Tue, Jun 1, 2021 at 6:46 PM Jeff Pyle  wrote:
>
> In my experience you don't need drop() in the reply route.  Just store
> the AVP and move on.  Something like this:
>
>
>
> onreply_route[collect_identity] {
>
> if (is_present_hf("Identity")) {
>
> $avp(identity) := $hdr(Identity);
>
> setflag("GOT_IDENTITY");
>
> }
>
> }
>
>
>
> If you've armed both the reply and failure routes with t_on_reply() and
> t_on_failure(), the $avp(identity) variable set here will be available in
> the failure_route.  The GOT_IDENTITY flag, too.
>
>
>
>
>
> - Jeff
>
>
>
>
>
>
>
> - Jeff
>
>
>
>
>
> On Tue, Jun 1, 2021 at 11:20 AM David Villasmil <
> david.villasmil.w...@gmail.com> wrote:
>
> Yes, I see it is documented.
>
>
>
> So the reply header is only availanble on the "onreply" route, not on the
> "failure" route. That was my problem. I do indeed use an avp to store the
> header.
>
> I ended up getting the header on the "onreply" and storing it in an avp,
> set a flag and then drop(). I noticed the "failure" route is then executed.
>
> From there I can send the processing to the invite route and by  checking
> the flag, adding the header from the avp.
>
>
>
> Thanks for your help!
>
>
> Regards,
>
>
>
> David Villasmil
>
> email: david.villasmil.w...@gmail.com
>
> phone: +34669448337
>
>
>
>
>
> On Tue, Jun 1, 2021 at 3:52 PM Ben Newlin  wrote:
>
> It’s documented that it works this way. The message being processed in
> failure_route is the original request; in reply_route it’s the reply. [1]
>
>
>
> You can use variable context to access the reply from failure_route [2].
> Another option would be to extract the header value into and AVP in
> reply_route and then reference the AVP from failure_route.
>
>
>
>
>
> [1] - https://www.opensips.org/Documentation/Script-Routes-3-2
>
> [2] - https://www.opensips.org/Documentation/Script-CoreVar-3-2
>
>
>
> Ben Newlin
>
>
>
> *From: *Users  on behalf of David
> Villasmil 
> *Date: *Tuesday, June 1, 2021 at 10:43 AM
> *To: *OpenSIPS users mailling list 
> *Subject: *Re: [OpenSIPS-Users] Getting header from 302
>
> Yeah, my thing is when i use the failure route i can in theory grab the
> response header and ignore the 302 and send to the invite route again to
> actually send the call out via do_routing.
>
> What I'm trying to do is:
>
> - On receiving an invite: forward to an endpoint.
>
> - This endpoint will simply reply with 302 including a header.
>
> - I want to grab that header and continue routing normally (do_routing)
>
>
>
> I could do that with the failure route, but not so sure about the onreply
> route.
>
>
> Regards,
>
>
>
> David Villasmil
>
> email: david.villasmil.w...@gmail.com
>
> phone: +34669448337
>
>
>
>
>
> On Tue, Jun 1, 2021 at 2:34 PM Jeff Pyle  wrote:
>
> I don't think you're doing anything wrong.  I think I found the same
> thing, that headers on the reply were available only in a reply route and
> not in a failure route.  If you know where to look for them to populate the
> AVP, I suppose it doesn't matter much.
>
>
>
> I haven't looked at the code but I suspect all the routes other than an
> onreply_route give you access to the requests headers, and onreply_route
> gives you access to the reply headers.  Makes sense I guess.
>
>
>
>
>
> - Jeff
>
>
>
>
>
> On Tue, Jun 1, 2021 at 9:31 AM David Villasmil <
> david.villasmil.w...@gmail.com> wrote:
>
> Thanks Jeff,
>
>
>
> MMM, that's strange, I was using it on failure route and the route was
> being executed, but the data wasn't there. I put it on the onreply route
> and that one is now executed with the data correctly there...
>
>
>
> I probably did something wrong.
>
>
>
> Thanks again Jeff!
>
>
> Regards,
>
>
>
> David Villasmil
>
> email: david.villasmil.w..

Re: [OpenSIPS-Users] MS teams, reinvite after ACK

[Jeff Pyle]

Right.  Something like this:

if (list_hdr_has_option("Allow", "REFER"))
list_hdr_remove_option("Allow", "REFER");

We've used blind transfer successfully.  If I remember correctly it will
utilize re-INVITEs, possibly with Replaces.  I don't know that we've tested
attended transfer.

OpenSIPS is just a proxy (in this case), so it will pass the REFER just
fine.  You'd probably have to do a lot of cleanup of the Refer-to value to
make it usable in this case...I haven't checked.  It all depends on what
you have upstream and what it can handle.  We opted to strip REFER for
simplicity.


- Jeff


On Wed, Jun 2, 2021 at 5:38 AM Miha via Users 
wrote:

> yes. Thank you.
>
> is there any way to get also attended transfer working?
>
> Johan De Clercq je 6/2/2021 ob 11:21 AM napisal:
>
> remove Refer from your supported methods.
> Do note that attended transfer will not work in this case.
>
> wkr,
>
> Op wo 2 jun. 2021 om 10:15 schreef Miha via Users <
> users@lists.opensips.org>:
>
>> Hello
>>
>> i manage to fix this. I did not do t_relay() also seq Invites, after this
>> everything works ok.
>>
>> Just on question, regarding transfers, i see that MS Teams send REFER in
>> which trafter is defined. How do you deal with this? You do not allow REFER
>> from MS teams and hope that MS teams will send new INVITE?
>>
>>
>> thank you
>> miha
>>
>> Jeff Pyle je 6/1/2021 ob 3:26 PM napisal:
>>
>> Miha,
>>
>> First, do you need to use "mtsbc.test.com:5060" in the first
>> record_route_preset() param?  Can you use the IP address of your proxy
>> instead?  FQDNs are legal of course, but outside of MS Teams'
>> implementation, they're rarely required.  It's just another thing to go
>> wrong.  Especially while testing.
>>
>> The ACK to the 200 OK is a sequential (in-dialog) request.  It's not part
>> of the original INVITE transaction.  Your script will have a section like
>>
>> if (has_totag()) {
>> if (loose_route()) {
>> t_relay();
>> }
>> }
>>
>> for sequential requests through a loose-routing proxy.  This is very
>> oversimplified and yours will have more.  In this section, however, is
>> where you'll process the ACK because it has a to-tag (line 293) and a route
>> header (line 298) so the conditions match.
>>
>> Use xlogs or the debug tool of your choice to diagnose what's happening
>> in this section with the ACK.  In my scripts, I use global flag 0 to
>> indicate when I want logging.  So, I might have something like this:
>>
>>if (has_totag()) {
>>if (is_gflag(0)) xlog("L_NOTICE", " ...in-dialog $rm
>> request\n");
>># ...do all the things...maybe more logging like the line
>> above...
>>
>>
>> - Jeff
>>
>>
>> On Tue, Jun 1, 2021 at 4:57 AM Miha via Users 
>> wrote:
>>
>>> Hello
>>>
>>>
>>> I have an issue and I am unable to find out what is wrong. Incoming
>>> calls are working but when doing outbound call after 200OK, which is send
>>> to Teams I get back ACK and after that Teams do again initial. I guess this
>>> is not ok.
>>>
>>> I am doing this for outband calls:
>>>
>>>
>>> xlog("L_INFO", "rtp rtps record route");
>>> record_route_preset("mtsbc.test.com:5060","mtsbc.test.com
>>> :5061;transport=tls");
>>> add_rr_param(";r2=on");
>>>
>>> I am pasting here trace. Opensips is in the middle.
>>>
>>> Thank you for help!
>>>
>>> https://pastebin.com/qM0dMiCc
>>> ___
>>> 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
>>
>
> ___
> 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] Am I seeing SIP message fragmentation?

[Răzvan Crainea]

Hi, Mark!

If that's the case, the problem is not the blank line the client is 
sending (that's fine, as it means there's no body), but the fact that it 
sends the garbage text - that text is indeed considered by OpenSIPS as 
part of a new message (what else can it be after all?) and is appended 
to the next message, hence the parsing fails.


Best regards,

Răzvan Crainea
OpenSIPS Core Developer
http://www.opensips-solutions.com

On 6/2/21 12:45 PM, Mark Allen wrote:

Hi Răzvan - thanks for the reply

Looking into it, our working theory is that the problem is as follows...

UAC (WebRTC dialer) is sending a corrupted SIP 200OK to an OPTIONS 
message over WebSocket. Message has a blank line in it and the content 
length is 0. OpenSIPS sees the blank line as the end of the SIP message 
but UAC is sending more (garbage text) after the blank line. I assume 
that what comes after the blank line is buffered and seen as the start 
of a new SIP message? When the next SIP message comes in it gets 
appended to the corrupt message segment and when OpenSIPS tries to parse 
it, it sees it as nonsense (which it is).


Just waiting on testing a new version of UAC which will hopefully 
confirm that this is the problem.


cheers,

M

On Wed, 2 Jun 2021 at 08:57, Răzvan Crainea > wrote:


Hi, Mark!

Most likely the problem appear prior to that Contact header you're
seeing - somehow OpenSIPS thinks the packet starts with the Contact
token, whereas, most likely, the Contact is part of a previous message,
not shown in this report.
There's no such thing as SIP message fragmentation - it's either UDP or
TCP fragmentation. However, fragmentation only appears when the package
is higher than MTU. I don't think this is the case here - What I think
there is, is a broken UA which is not setting a correct Content-Length,
or is sending garbage after sending the packet. But the only way to
figure out is to make a pcap for the entire connection and see where it
starts breaking.

Best regards,

Răzvan Crainea
OpenSIPS Core Developer
http://www.opensips-solutions.com 

On 5/26/21 2:15 PM, Mark Allen wrote:
 > I'm seeing a weird, intermittent error. The most common
occurrence is
 > with a 200OK returned by Mid-Registrar on a re-REGISTER using
 > registration throttling, but we see it elsewhere. It appears that
the
 > 200OK message is getting garbled.
 >
 > We have a bit of a weird setup to overcome issues we were having
with
 > Mid-Registrar and WebSocket addressing. Mid-Registrar is looping
back
 > 200OK to OpenSIPS before it then gets sent down the WebSocket.
90+% of
 > the time it's absolutely fine, but occasionally the 200OK seems
to be
 > corrupted.
 >
 > Here's an example. What we are seeing in this message is...
 >
 >      Contact: http://sip:1...@abc.def.com:5060> >>
 >      User-Agent: MWWRTC 3.4.21042#015#012Accept:
 > application/sdp,application/dtmf-relay,text/plain
 >
 > ...preceding...
 >
 >      SIP/2.0 200 OK
 >      Via: SIP/2.0/TCP
 >

192.168.1.23:5060;received=192.168.1.23;rport=42385;branch=z9hG4bK22a8.4fa6d127.0;i=b4986fe4
 >      ...etc...
 >
 > ...so OpenSIPS is failing to parse the message.
 >
 > What I'd like to know is, is this a sign of SIP message
fragmentation?
 >
 >
 >
 > Log entries (IP addresses, domains, and extensions changed to
protect
 > the innocent!):
 >
 > ERROR:core:parse_method: invalid character :
 > DBG:core:tcp_read_req: tcp_read_req end
 > INFO:core:parse_first_line: failed to parse the method
 > INFO:core:parse_first_line: bad message
 > DBG:core:parse_msg: invalid message
 > ERROR:core:parse_msg: message=http://sip:1...@abc.def.com:5060>
 > >>#015#012User-Agent: MWWRTC
 > 3.4.21042#015#012Accept:
 > application/sdp,application/dtmf-relay,text/plain#015#012SIP/2.0 200
 > OK#015#012Via: SIP/2.0/TCP
 >

192.168.1.23:5060;received=192.168.1.23;rport=42385;branch=z9hG4bK22a8.4fa6d127.0;i=b4986fe4#015#012Via:

 > SIP/2.0/WSS
 >

98kaag0xmybq.invalid;received=4.56.78.110;branch=z9hG4bKU6O3fJQGeLvuACMTXTArJgJW73rOD5dU;rport=52570#015#012From:

 > mailto:sip%3a1...@abc.def.com>
 > >>;tag=Lyk010G476K7xcKrE84M#015#012To:
 > mailto:sip%3a1...@abc.def.com>
 > >>;tag=af78-6213d386c3edcd02707b0c0aa8423d3a#015#012Call-ID:

 > 666b5e7c-cef3-f306-4b79-60d3160dc5d0#015#012CSeq: 28825
 > REGISTER#015#012Contact:
 >

;expires=60;received="sip:4.56.78.110:

Re: [OpenSIPS-Users] Am I seeing SIP message fragmentation?

[Mark Allen]

Hi Răzvan - thanks for the reply

Looking into it, our working theory is that the problem is as follows...

UAC (WebRTC dialer) is sending a corrupted SIP 200OK to an OPTIONS message
over WebSocket. Message has a blank line in it and the content length is 0.
OpenSIPS sees the blank line as the end of the SIP message but UAC is
sending more (garbage text) after the blank line. I assume that what comes
after the blank line is buffered and seen as the start of a new SIP
message? When the next SIP message comes in it gets appended to the corrupt
message segment and when OpenSIPS tries to parse it, it sees it as nonsense
(which it is).

Just waiting on testing a new version of UAC which will hopefully confirm
that this is the problem.

cheers,

M

On Wed, 2 Jun 2021 at 08:57, Răzvan Crainea  wrote:

> Hi, Mark!
>
> Most likely the problem appear prior to that Contact header you're
> seeing - somehow OpenSIPS thinks the packet starts with the Contact
> token, whereas, most likely, the Contact is part of a previous message,
> not shown in this report.
> There's no such thing as SIP message fragmentation - it's either UDP or
> TCP fragmentation. However, fragmentation only appears when the package
> is higher than MTU. I don't think this is the case here - What I think
> there is, is a broken UA which is not setting a correct Content-Length,
> or is sending garbage after sending the packet. But the only way to
> figure out is to make a pcap for the entire connection and see where it
> starts breaking.
>
> Best regards,
>
> Răzvan Crainea
> OpenSIPS Core Developer
> http://www.opensips-solutions.com
>
> On 5/26/21 2:15 PM, Mark Allen wrote:
> > I'm seeing a weird, intermittent error. The most common occurrence is
> > with a 200OK returned by Mid-Registrar on a re-REGISTER using
> > registration throttling, but we see it elsewhere. It appears that the
> > 200OK message is getting garbled.
> >
> > We have a bit of a weird setup to overcome issues we were having with
> > Mid-Registrar and WebSocket addressing. Mid-Registrar is looping back
> > 200OK to OpenSIPS before it then gets sent down the WebSocket. 90+% of
> > the time it's absolutely fine, but occasionally the 200OK seems to be
> > corrupted.
> >
> > Here's an example. What we are seeing in this message is...
> >
> >  Contact:  http://sip:1...@abc.def.com:5060>>
> >  User-Agent: MWWRTC 3.4.21042#015#012Accept:
> > application/sdp,application/dtmf-relay,text/plain
> >
> > ...preceding...
> >
> >  SIP/2.0 200 OK
> >  Via: SIP/2.0/TCP
> > 192.168.1.23:5060
> ;received=192.168.1.23;rport=42385;branch=z9hG4bK22a8.4fa6d127.0;i=b4986fe4
> >  ...etc...
> >
> > ...so OpenSIPS is failing to parse the message.
> >
> > What I'd like to know is, is this a sign of SIP message fragmentation?
> >
> >
> >
> > Log entries (IP addresses, domains, and extensions changed to protect
> > the innocent!):
> >
> > ERROR:core:parse_method: invalid character :
> > DBG:core:tcp_read_req: tcp_read_req end
> > INFO:core:parse_first_line: failed to parse the method
> > INFO:core:parse_first_line: bad message
> > DBG:core:parse_msg: invalid message
> > ERROR:core:parse_msg: message= > >#015#012User-Agent: MWWRTC
> > 3.4.21042#015#012Accept:
> > application/sdp,application/dtmf-relay,text/plain#015#012SIP/2.0 200
> > OK#015#012Via: SIP/2.0/TCP
> > 192.168.1.23:5060;received=192.168.1.23;rport=42385;branch=z9hG4bK22a8.4fa6d127.0;i=b4986fe4#015#012Via:
>
> > SIP/2.0/WSS
> >
> 98kaag0xmybq.invalid;received=4.56.78.110;branch=z9hG4bKU6O3fJQGeLvuACMTXTArJgJW73rOD5dU;rport=52570#015#012From:
>
> >  > >;tag=Lyk010G476K7xcKrE84M#015#012To:
> >  > >;tag=af78-6213d386c3edcd02707b0c0aa8423d3a#015#012Call-ID:
>
> > 666b5e7c-cef3-f306-4b79-60d3160dc5d0#015#012CSeq: 28825
> > REGISTER#015#012Contact:
> > ;expires=60;received="sip:
> 4.56.78.110:52570
> > "#015#012Server: OpenSIPS (3.1.1
> > (x86_64/linux))#015#012Content-Length: 0#015#012#015#012>
> > ERROR:core:receive_msg: Unable to parse msg received from
> > [192.168.1.23:5060 ]
> > ERROR:core:tcp_handle_req: receive_msg failed
> > DBG:core:tcp_read_req: tcp_read_req end
> >
> > ___
> > 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
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] MS teams, reinvite after ACK

[Miha via Users]

yes. Thank you.

is there any way to get also attended transfer working?

Johan De Clercq je 6/2/2021 ob 11:21 AM napisal:

remove Refer from your supported methods.
Do note that attended transfer will not work in this case.

wkr,

Op wo 2 jun. 2021 om 10:15 schreef Miha via Users 
mailto:users@lists.opensips.org>>:


Hello

i manage to fix this. I did not do t_relay() also seq Invites,
after this everything works ok.

Just on question, regarding transfers, i see that MS Teams send
REFER in which trafter is defined. How do you deal with this? You
do not allow REFER from MS teams and hope that MS teams will send
new INVITE?


thank you
miha

Jeff Pyle je 6/1/2021 ob 3:26 PM napisal:

Miha,

First, do you need to use "mtsbc.test.com:5060
" in the first record_route_preset()
param?  Can you use the IP address of your proxy instead?  FQDNs
are legal of course, but outside of MS Teams' implementation,
they're rarely required.  It's just another thing to go wrong. 
Especially while testing.

The ACK to the 200 OK is a sequential (in-dialog) request.  It's
not part of the original INVITE transaction.  Your script will
have a section like

if (has_totag()) {
if (loose_route()) {
t_relay();
}
}

for sequential requests through a loose-routing proxy.  This is
very oversimplified and yours will have more.  In this section,
however, is where you'll process the ACK because it has a to-tag
(line 293) and a route header (line 298) so the conditions match.

Use xlogs or the debug tool of your choice to diagnose what's
happening in this section with the ACK.  In my scripts, I use
global flag 0 to indicate when I want logging.  So, I might have
something like this:

   if (has_totag()) {
   if (is_gflag(0)) xlog("L_NOTICE", "...in-dialog
$rm request\n");
# ...do all the things...maybe more logging like the line above...


- Jeff


On Tue, Jun 1, 2021 at 4:57 AM Miha via Users
mailto:users@lists.opensips.org>> wrote:

Hello


I have an issue and I am unable to find out what is wrong.
Incoming calls are working but when doing outbound call after
200OK, which is send to Teams I get back ACK and after that
Teams do again initial. I guess this is not ok.

I am doing this for outband calls:


xlog("L_INFO", "rtp rtps record route");
record_route_preset("mtsbc.test.com:5060
","mtsbc.test.com
:5061;transport=tls");
add_rr_param(";r2=on");

I am pasting here trace. Opensips is in the middle.

Thank you for help!

https://pastebin.com/qM0dMiCc 
___
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




___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] MS teams, reinvite after ACK

[Johan De Clercq]

remove Refer from your supported methods.
Do note that attended transfer will not work in this case.

wkr,

Op wo 2 jun. 2021 om 10:15 schreef Miha via Users :

> Hello
>
> i manage to fix this. I did not do t_relay() also seq Invites, after this
> everything works ok.
>
> Just on question, regarding transfers, i see that MS Teams send REFER in
> which trafter is defined. How do you deal with this? You do not allow REFER
> from MS teams and hope that MS teams will send new INVITE?
>
>
> thank you
> miha
>
> Jeff Pyle je 6/1/2021 ob 3:26 PM napisal:
>
> Miha,
>
> First, do you need to use "mtsbc.test.com:5060" in the first
> record_route_preset() param?  Can you use the IP address of your proxy
> instead?  FQDNs are legal of course, but outside of MS Teams'
> implementation, they're rarely required.  It's just another thing to go
> wrong.  Especially while testing.
>
> The ACK to the 200 OK is a sequential (in-dialog) request.  It's not part
> of the original INVITE transaction.  Your script will have a section like
>
> if (has_totag()) {
> if (loose_route()) {
> t_relay();
> }
> }
>
> for sequential requests through a loose-routing proxy.  This is very
> oversimplified and yours will have more.  In this section, however, is
> where you'll process the ACK because it has a to-tag (line 293) and a route
> header (line 298) so the conditions match.
>
> Use xlogs or the debug tool of your choice to diagnose what's happening in
> this section with the ACK.  In my scripts, I use global flag 0 to indicate
> when I want logging.  So, I might have something like this:
>
>if (has_totag()) {
>if (is_gflag(0)) xlog("L_NOTICE", " ...in-dialog $rm
> request\n");
># ...do all the things...maybe more logging like the line
> above...
>
>
> - Jeff
>
>
> On Tue, Jun 1, 2021 at 4:57 AM Miha via Users 
> wrote:
>
>> Hello
>>
>>
>> I have an issue and I am unable to find out what is wrong. Incoming calls
>> are working but when doing outbound call after 200OK, which is send to
>> Teams I get back ACK and after that Teams do again initial. I guess this is
>> not ok.
>>
>> I am doing this for outband calls:
>>
>>
>> xlog("L_INFO", "rtp rtps record route");
>> record_route_preset("mtsbc.test.com:5060","mtsbc.test.com
>> :5061;transport=tls");
>> add_rr_param(";r2=on");
>>
>> I am pasting here trace. Opensips is in the middle.
>>
>> Thank you for help!
>>
>> https://pastebin.com/qM0dMiCc
>> ___
>> 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
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] MS teams, reinvite after ACK

[Miha via Users]

ok, it does new seq invite, so not is is working.


thank you for help.
miha

Miha via Users je 6/2/2021 ob 10:11 AM napisal:

Hello

i manage to fix this. I did not do t_relay() also seq Invites, after 
this everything works ok.


Just on question, regarding transfers, i see that MS Teams send REFER 
in which trafter is defined. How do you deal with this? You do not 
allow REFER from MS teams and hope that MS teams will send new INVITE?



thank you
miha

Jeff Pyle je 6/1/2021 ob 3:26 PM napisal:

Miha,

First, do you need to use "mtsbc.test.com:5060 
" in the first record_route_preset() 
param?  Can you use the IP address of your proxy instead?  FQDNs are 
legal of course, but outside of MS Teams' implementation, they're 
rarely required.  It's just another thing to go wrong. Especially 
while testing.


The ACK to the 200 OK is a sequential (in-dialog) request.  It's not 
part of the original INVITE transaction. Your script will have a 
section like


if (has_totag()) {
if (loose_route()) {
t_relay();
}
}

for sequential requests through a loose-routing proxy.  This is very 
oversimplified and yours will have more.  In this section, however, 
is where you'll process the ACK because it has a to-tag (line 293) 
and a route header (line 298) so the conditions match.


Use xlogs or the debug tool of your choice to diagnose what's 
happening in this section with the ACK.  In my scripts, I use global 
flag 0 to indicate when I want logging.  So, I might have something 
like this:


   if (has_totag()) {
   if (is_gflag(0)) xlog("L_NOTICE", "...in-dialog $rm 
request\n");

# ...do all the things...maybe more logging like the line above...


- Jeff


On Tue, Jun 1, 2021 at 4:57 AM Miha via Users 
mailto:users@lists.opensips.org>> wrote:


Hello


I have an issue and I am unable to find out what is wrong.
Incoming calls are working but when doing outbound call after
200OK, which is send to Teams I get back ACK and after that Teams
do again initial. I guess this is not ok.

I am doing this for outband calls:


xlog("L_INFO", "rtp rtps record route");
record_route_preset("mtsbc.test.com:5060
","mtsbc.test.com
:5061;transport=tls");
add_rr_param(";r2=on");

I am pasting here trace. Opensips is in the middle.

Thank you for help!

https://pastebin.com/qM0dMiCc 
___
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


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] MS teams, reinvite after ACK

[Miha via Users]

Hello

i manage to fix this. I did not do t_relay() also seq Invites, after 
this everything works ok.


Just on question, regarding transfers, i see that MS Teams send REFER in 
which trafter is defined. How do you deal with this? You do not allow 
REFER from MS teams and hope that MS teams will send new INVITE?



thank you
miha

Jeff Pyle je 6/1/2021 ob 3:26 PM napisal:

Miha,

First, do you need to use "mtsbc.test.com:5060 
" in the first record_route_preset() 
param?  Can you use the IP address of your proxy instead?  FQDNs are 
legal of course, but outside of MS Teams' implementation, they're 
rarely required. It's just another thing to go wrong.  Especially 
while testing.


The ACK to the 200 OK is a sequential (in-dialog) request. It's not 
part of the original INVITE transaction.  Your script will have a 
section like


if (has_totag()) {
if (loose_route()) {
t_relay();
}
}

for sequential requests through a loose-routing proxy.  This is very 
oversimplified and yours will have more.  In this section, however, is 
where you'll process the ACK because it has a to-tag (line 293) and a 
route header (line 298) so the conditions match.


Use xlogs or the debug tool of your choice to diagnose what's 
happening in this section with the ACK.  In my scripts, I use global 
flag 0 to indicate when I want logging.  So, I might have something 
like this:


   if (has_totag()) {
   if (is_gflag(0)) xlog("L_NOTICE", "...in-dialog $rm 
request\n");

# ...do all the things...maybe more logging like the line above...


- Jeff


On Tue, Jun 1, 2021 at 4:57 AM Miha via Users 
mailto:users@lists.opensips.org>> wrote:


Hello


I have an issue and I am unable to find out what is wrong.
Incoming calls are working but when doing outbound call after
200OK, which is send to Teams I get back ACK and after that Teams
do again initial. I guess this is not ok.

I am doing this for outband calls:


xlog("L_INFO", "rtp rtps record route");
record_route_preset("mtsbc.test.com:5060
","mtsbc.test.com
:5061;transport=tls");
add_rr_param(";r2=on");

I am pasting here trace. Opensips is in the middle.

Thank you for help!

https://pastebin.com/qM0dMiCc 
___
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] Am I seeing SIP message fragmentation?

[Răzvan Crainea]

Hi, Mark!

Most likely the problem appear prior to that Contact header you're 
seeing - somehow OpenSIPS thinks the packet starts with the Contact 
token, whereas, most likely, the Contact is part of a previous message, 
not shown in this report.
There's no such thing as SIP message fragmentation - it's either UDP or 
TCP fragmentation. However, fragmentation only appears when the package 
is higher than MTU. I don't think this is the case here - What I think 
there is, is a broken UA which is not setting a correct Content-Length, 
or is sending garbage after sending the packet. But the only way to 
figure out is to make a pcap for the entire connection and see where it 
starts breaking.


Best regards,

Răzvan Crainea
OpenSIPS Core Developer
http://www.opensips-solutions.com

On 5/26/21 2:15 PM, Mark Allen wrote:
I'm seeing a weird, intermittent error. The most common occurrence is 
with a 200OK returned by Mid-Registrar on a re-REGISTER using 
registration throttling, but we see it elsewhere. It appears that the 
200OK message is getting garbled.


We have a bit of a weird setup to overcome issues we were having with 
Mid-Registrar and WebSocket addressing. Mid-Registrar is looping back 
200OK to OpenSIPS before it then gets sent down the WebSocket. 90+% of 
the time it's absolutely fine, but occasionally the 200OK seems to be 
corrupted.


Here's an example. What we are seeing in this message is...

     Contact: http://sip:1...@abc.def.com:5060>>
     User-Agent: MWWRTC 3.4.21042#015#012Accept: 
application/sdp,application/dtmf-relay,text/plain


...preceding...

     SIP/2.0 200 OK
     Via: SIP/2.0/TCP 
192.168.1.23:5060;received=192.168.1.23;rport=42385;branch=z9hG4bK22a8.4fa6d127.0;i=b4986fe4

     ...etc...

...so OpenSIPS is failing to parse the message.

What I'd like to know is, is this a sign of SIP message fragmentation?



Log entries (IP addresses, domains, and extensions changed to protect 
the innocent!):


ERROR:core:parse_method: invalid character :
DBG:core:tcp_read_req: tcp_read_req end
INFO:core:parse_first_line: failed to parse the method
INFO:core:parse_first_line: bad message
DBG:core:parse_msg: invalid message
ERROR:core:parse_msg: message=>#015#012User-Agent: MWWRTC 
3.4.21042#015#012Accept: 
application/sdp,application/dtmf-relay,text/plain#015#012SIP/2.0 200 
OK#015#012Via: SIP/2.0/TCP 
192.168.1.23:5060;received=192.168.1.23;rport=42385;branch=z9hG4bK22a8.4fa6d127.0;i=b4986fe4#015#012Via: 
SIP/2.0/WSS 
98kaag0xmybq.invalid;received=4.56.78.110;branch=z9hG4bKU6O3fJQGeLvuACMTXTArJgJW73rOD5dU;rport=52570#015#012From: 
>;tag=Lyk010G476K7xcKrE84M#015#012To: 
>;tag=af78-6213d386c3edcd02707b0c0aa8423d3a#015#012Call-ID: 
666b5e7c-cef3-f306-4b79-60d3160dc5d0#015#012CSeq: 28825 
REGISTER#015#012Contact: 
;expires=60;received="sip:4.56.78.110:52570 
"#015#012Server: OpenSIPS (3.1.1 
(x86_64/linux))#015#012Content-Length: 0#015#012#015#012>
ERROR:core:receive_msg: Unable to parse msg received from 
[192.168.1.23:5060 ]

ERROR:core:tcp_handle_req: receive_msg failed
DBG:core:tcp_read_req: tcp_read_req end

___
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] opensips 3.2 B2B module and RTPProxy/RTPEngine

[Răzvan Crainea]

Hi, Xaled!

You can engange RTPengine for a B2B session, however you will have to 
make sure that you are using the correct callid/from-tag/to-tag for the 
entire communication to RTPengine. To do so, I would recommend you start 
with a rtengine_offer() for the initial invite, then store the 
callid/from-tag/to-tag in the $b2b_logic.ctx [1], and use those keys in 
all the sequential requests/replies.


[1] https://opensips.org/docs/modules/3.2.x/b2b_logic.html#b2b_logic.ctx

Best regards,

Răzvan Crainea
OpenSIPS Core Developer
http://www.opensips-solutions.com

On 5/26/21 12:27 PM, David Villasmil wrote:

Are you 100% sure opensips can “talk” to rtpengine? How do you know?

On Wed, 26 May 2021 at 09:24, mailto:xa...@web.de>> wrote:

Apologies for keep on bugging on this issue, but would really
appreciate any hints.

-Original Message-
From: Users mailto:users-boun...@lists.opensips.org>> On Behalf Of xa...@web.de

Sent: Wednesday, May 19, 2021 1:30 PM
To: 'OpenSIPS users mailling list' mailto:users@lists.opensips.org>>
Subject: Re: [OpenSIPS-Users] opensips 3.2 B2B module and
RTPProxy/RTPEngine

Hi

Would appreciate any hints on how to run the new 3.2 B2B module with
RTPProxy or RTPEngine.

Thanks,
Xaled
-Original Message-
From: Users mailto:users-boun...@lists.opensips.org>> On Behalf Of xa...@web.de

Sent: Friday, May 14, 2021 1:34 PM
To: 'OpenSIPS users mailling list' mailto:users@lists.opensips.org>>
Subject: [OpenSIPS-Users] opensips 3.2 B2B module and RTPProxy/RTPEngine

Hi,

Are the any examples of using the new B2B module in 3.2 with
RTPProxy or RTPEngine? I tried adding _offer and _answer call
accordingly but never saw RTPProxy or RTPEngine engaged.

Even a simple example for A-B call with B2B and RTPEngine would be
much appreciated.

Thanks,
Xaled


___
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



___
Users mailing list
Users@lists.opensips.org 
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


--
Regards,

David Villasmil
email: david.villasmil.w...@gmail.com 


phone: +34669448337

___
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] Getting header from 302

[Ben Newlin]

You still don’t need to call drop() as long as you are handling the request in 
failure_route. The 302 will not be sent back upstream as long as failure_route 
either creates a new branch request or sends back a different reply code. Only 
if failure_route exits without doing either of these things would the 
downstream 302 be sent back upstream as-is.

In fact, as far as I know drop() has no functionality for responses >= 200.

Ben Newlin

From: Users  on behalf of Jeff Pyle 

Date: Tuesday, June 1, 2021 at 2:48 PM
To: OpenSIPS users mailling list 
Subject: Re: [OpenSIPS-Users] Getting header from 302
Oh!  Understood.


- Jeff


On Tue, Jun 1, 2021 at 2:42 PM David Villasmil 
mailto:david.villasmil.w...@gmail.com>> wrote:
The thing is I _want_ to drop the 302, I don't want to do anything else with it.

Regards,

David Villasmil
email: david.villasmil.w...@gmail.com
phone: +34669448337


On Tue, Jun 1, 2021 at 6:46 PM Jeff Pyle mailto:j...@ugnd.org>> 
wrote:
In my experience you don't need drop() in the reply route.  Just store the AVP 
and move on.  Something like this:

onreply_route[collect_identity] {
if (is_present_hf("Identity")) {
$avp(identity) := $hdr(Identity);
setflag("GOT_IDENTITY");
}
}

If you've armed both the reply and failure routes with t_on_reply() and 
t_on_failure(), the $avp(identity) variable set here will be available in the 
failure_route.  The GOT_IDENTITY flag, too.


- Jeff



- Jeff


On Tue, Jun 1, 2021 at 11:20 AM David Villasmil 
mailto:david.villasmil.w...@gmail.com>> wrote:
Yes, I see it is documented.

So the reply header is only availanble on the "onreply" route, not on the 
"failure" route. That was my problem. I do indeed use an avp to store the 
header.
I ended up getting the header on the "onreply" and storing it in an avp, set a 
flag and then drop(). I noticed the "failure" route is then executed.
>From there I can send the processing to the invite route and by  checking the 
>flag, adding the header from the avp.

Thanks for your help!

Regards,

David Villasmil
email: david.villasmil.w...@gmail.com
phone: +34669448337


On Tue, Jun 1, 2021 at 3:52 PM Ben Newlin 
mailto:ben.new...@genesys.com>> wrote:
It’s documented that it works this way. The message being processed in 
failure_route is the original request; in reply_route it’s the reply. [1]

You can use variable context to access the reply from failure_route [2]. 
Another option would be to extract the header value into and AVP in reply_route 
and then reference the AVP from failure_route.


[1] - 
https://www.opensips.org/Documentation/Script-Routes-3-2
[2] - 
https://www.opensips.org/Documentation/Script-CoreVar-3-2

Ben Newlin

From: Users 
mailto:users-boun...@lists.opensips.org>> on 
behalf of David Villasmil 
mailto:david.villasmil.w...@gmail.com>>
Date: Tuesday, June 1, 2021 at 10:43 AM
To: OpenSIPS users mailling list 
mailto:users@lists.opensips.org>>
Subject: Re: [OpenSIPS-Users] Getting header from 302
Yeah, my thing is when i use the failure route i can in theory grab the 
response header and ignore the 302 and send to the invite route again to 
actually send the call out via do_routing.
What I'm trying to do is:
- On receiving an invite: forward to an endpoint.
- This endpoint will simply reply with 302 including a header.
- I want to grab that header and continue routing normally (do_routing)

I could do that with the failure route, but not so sure about the onreply route.

Regards,

David Villasmil
email: david.villasmil.w...@gmail.com
phone: +34669448337


On Tue, Jun 1, 2021 at 2:34 PM Jeff Pyle mailto:j...@ugnd.org>> 
wrote:
I don't think you're doing anything wrong.  I think I found the same thing, 
that headers on the reply were available only in a reply route and not in a 
failure route.  If you know where to look for them to populate the AVP, I 
suppose it doesn't matter much.

I haven't looked at the code but I suspect all the routes other than an 
onreply_route give you access to the requests headers, and onreply_route gives 
you access to the reply headers.  Makes sense I guess.


- Jeff


On Tue, Jun 1, 2021 at 9:31 AM David Villasmil 
mailto:david.villasmil.w...@gmail.com>> wrote:
Thanks Jeff,

MMM, that's strange, I was using it on failure route and the route was being 
executed, but the data wasn't there. I put it on the onreply route and that one 
is now executed with the data correctly there...

I probably did something wrong.

Thanks again Jeff!

Regards,

David Villasmil
email: david.villasmil.w...@gmail.com
phone: +34669448337


On Tue, Jun 1, 2021 at 12:37 PM Jeff Pyle mailto:j...@ugnd.org>> 
wrote:
In which route are you trying to use if (is_present_hf("Identity"))?  Since the 
302 i