15 Oct
2018
15 Oct
'18
1:57 p.m.
Then the UPDATE either has to follow the Record-Route stack received in
180, or be constructed like the initial INVITE with pre-loaded Route set.
I don't have the time to check the SIP specs right now, but by reusing
the Call-Id and From-tag and increasing the CSeq, this is more like a
request within dialog, but it doesn't use the To-tag from 180 and no
Route headers. So something needs to be fixed inside the UA, the proxy
is just following the routing headers that are present in the request.
Cheers,
Daniel
On 15.10.18 18:33, Sergiu Pojoga wrote:
Yes there was a 180 reply from the Callee.
2018/10/11 12:34:57.535510 65.xx.xx.161:64877 -> 65.xx.xx.167:5070
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP
65.xx.xx.167:5070;branch=z9hG4bK98e3.3392254b0b2d98dfc66f12cb7fdba746.0
Via: SIP/2.0/UDP 65.xx.xx.172:5060;rport=5060;branch=z9hG4bK694382a1
Record-Route: <sip:65.xx.xx.167:5070;r2=on;lr=on;did=bbf.658>
Record-Route: <sip:65.xx.xx.167;r2=on;lr=on;did=bbf.658>
Contact: <sip:238@10.17.0.35:64877 <http://sip:238@10.17.0.35:64877>>
To:
"John"<sip:238@65.xx.xx.161:64877;rinstance=8a315091627cc10b>;tag=6467b07f
From: "Robert" <sip:226@mypbx.net
<mailto:sip%3A226@mypbx.net>>;tag=as0ecef1c4
Call-ID: 1e82197b42f0173b25e70759753d4210(a)mypbx.net
<mailto:1e82197b42f0173b25e70759753d4210@mypbx.net>
CSeq: 102 INVITE
User-Agent: Bria 4 release 4.8.1 stamp 84929
Allow-Events: talk, hold
Content-Length: 0
2018/10/11 12:34:57.535631 65.xx.xx.167:5060 -> 65.xx.xx.172:5060
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 65.xx.xx.172:5060;rport=5060;branch=z9hG4bK694382a1
Record-Route: <sip:65.xx.xx.167:5070;r2=on;lr=on;did=bbf.658>
Record-Route: <sip:65.xx.xx.167;r2=on;lr=on;did=bbf.658>
Contact: <sip:238@10.17.0.35:64877;alias=65.xx.xx.161~64877~1>
To:
"John"<sip:238@65.xx.xx.161:64877;rinstance=8a315091627cc10b>;tag=6467b07f
From: "Robert" <sip:226@mypbx.net
<mailto:sip%3A226@mypbx.net>>;tag=as0ecef1c4
Call-ID: 1e82197b42f0173b25e70759753d4210(a)mypbx.net
<mailto:1e82197b42f0173b25e70759753d4210@mypbx.net>
CSeq: 102 INVITE
Allow-Events: talk, hold
Content-Length: 0
On Mon, Oct 15, 2018 at 12:15 PM Daniel-Constantin Mierla
<miconda(a)gmail.com <mailto:miconda@gmail.com>> wrote:
Hello,
indeed, I was misled by the Route headers in INVITE, which looked
like inside a dialog, but the parameter in To header is rinstance.
Is there any 18x response?
Cheers,
Daniel
On 15.10.18 16:00, Sergiu Pojoga wrote:
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference -- www.kamailioworld.com
Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com
Hi again,
Hmm... I don't see a To-tag in the INVITE, neither there's a
200OK to provide because the UPDATE was sent out prior to the
callee answering the call.
If there should be a Route header in the UPDATE, it would it
indicate a bug with Asterisk firing off the UPDATE without a
pre-set Route dictated by the Path?
If that's the case, I suppose my options are:
1. reach out to Asterisk to investigate and fix it (unrealistic)
2. store the Route header from the initial INVITE in a AVP and
insert it later if an UPDATE follows. Would that break
anything up?
Any other constructive suggestions?
Thanks.
On Mon, Oct 15, 2018 at 2:34 AM Daniel-Constantin Mierla
<miconda(a)gmail.com <mailto:miconda@gmail.com>> wrote:
Hello,
that seems to be a re-INVITE (has To-tag). I would need at
least the initial INVITE and the 200ok, along with the UPDATE
request.
If the UPDATE is after the re-INVITE, it is missing the Route
header as in the re-INVITE.
Cheers,
Daniel
On 12.10.18 16:53, Sergiu Pojoga wrote:
--
Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com>
www.twitter.com/miconda <http://www.twitter.com/miconda> --
www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
Kamailio World Conference -- www.kamailioworld.com
<http://www.kamailioworld.com>
Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com
<http://www.asipto.com>
Hi Daniel,
Certainly, below find the initial INVITE and the subsequent
UPDATE, as received by Kamailio(a)65.xx.xx.167
<mailto:Kamailio@65.xx.xx.167>. If those aren't sufficient,
let me know and if it's ok with you, I'll send the full pcap
in private.
The dilemma in my mind is whether the UPDATE should have a
pre-set Route header, similar to how the INVITE has.
2018/10/11 12:34:57.339306 65.xx.xx.172:5060 ->
65.xx.xx.167:5060
INVITE sip:238@65.xx.xx.161:64877;rinstance=8a315091627cc10b
SIP/2.0
Via: SIP/2.0/UDP 65.xx.xx.172:5060;branch=z9hG4bK694382a1
Max-Forwards: 70
Route:
<sip:65.xx.xx.167;lr;received=sip:65.xx.xx.161:64877;r2=on>,<sip:xx.xx.xx.167:5070;lr;received=sip:65.xx.xx.161:64877;r2=on>
From: "Robert" <sip:226@mypbx.net
<mailto:sip%3A226@mypbx.net>>;tag=as0ecef1c4
To: <sip:238@65.xx.xx.161:64877;rinstance=8a315091627cc10b>
Contact: <sip:226@65.xx.xx.172:5060>
Call-ID: 1e82197b42f0173b25e70759753d4210(a)mypbx.net
<mailto:1e82197b42f0173b25e70759753d4210@mypbx.net>
CSeq: 102 INVITE
Supported: replaces,
timer, path
Content-Type: application/sdp
Content-Length: 386
2018/10/11 12:35:06.096457 65.xx.xx.172:5060 ->
65.xx.xx.167:5060
UPDATE sip:238@10.17.0.35:64877;alias=65.xx.xx.161~64877~1
SIP/2.0
Via: SIP/2.0/UDP 65.xx.xx.172:5060;branch=z9hG4bK34fab05c
Max-Forwards: 70
From: "Robert" <sip:226@mypbx.net
<mailto:sip%3A226@mypbx.net>>;tag=as0ecef1c4
To:
<sip:238@65.xx.xx.161:64877;rinstance=8a315091627cc10b>;tag=6467b07f
Contact: <sip:226@65.xx.xx.172:5060>
Call-ID: 1e82197b42f0173b25e70759753d4210(a)mypbx.net
<mailto:1e82197b42f0173b25e70759753d4210@mypbx.net>
CSeq: 103 UPDATE
Content-Length: 0
Much obliged.
On Fri, Oct 12, 2018 at 9:38 AM Daniel-Constantin Mierla
<miconda(a)gmail.com <mailto:miconda@gmail.com>> wrote:
Hello,
you hve to provide the sip traffic for this case, the
screenshot doesn't show the sip headers used for routing
in this case, therefore grab the sip traffic for all sip
messages in such scenarion, either ngrep output or pcap
file, and send it over to see if some headers are
missing or not set properly.
Cheers,
Daniel
On 11.10.18 21:03, Sergiu Pojoga wrote:
--
Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com>
www.twitter.com/miconda <http://www.twitter.com/miconda> --
www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
Kamailio World Conference -- www.kamailioworld.com
<http://www.kamailioworld.com>
Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com
<http://www.asipto.com>
Hi ppl,
I have this problem with call transfer, may be someone
can help.
The phone to the far right is registered with the
Registrar to the far left using two PATH headers
(trespassing two proxy ports, 5070 then 5060).
As you can see in the graph below, after receiving the
UPDATE request, Kamailio relays it further from port
5060, I expect it to be from 5070 just like the dialog
forming INVITE and the CANCEL afterwards.
image.png
The UPDATE has a to-tag, but unlike the original INVITE
- it has no Route header!???
route[*WITHINDLG*] {
if (!has_totag()) return;
if (loose_route()) {
route(DLGURI);
if (is_method("BYE")) {
...
}
else if ( is_method("ACK") ) {
route(NATMANAGE);
}
else if ( is_method("NOTIFY") ) {
record_route();
}
route(RELAY);
exit;
}
if ( is_method("ACK") ) {
...
}
# handle UPDATE method for in-dialog requests
if (is_method("*UPDATE*")) {
route(DLGURI);
record_route();
route(RELAY);
}
}
Thanks in advance.
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
<mailto:sr-users@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com>
www.twitter.com/miconda <http://www.twitter.com/miconda> --
www.linkedin.com/in/miconda
<http://www.linkedin.com/in/miconda>
Kamailio World Conference -- www.kamailioworld.com
<http://www.kamailioworld.com>
Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com
<http://www.asipto.com>