Wrong ACK to Provider

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Wrong ACK to Provider

Yuriy Gorlichenko
Hello. I try to provide call scheme:

internal client  -> asterisk -> Kamailio -> provider -> external endpoint call

when I make call I see this:

asterisk     kamailio   provider
invite -->       invite -->   
                                <--     407
                       ACK   -->    
                       invite w/Auth -->
              <--    100  <--    100
              <--    180  <--    180
              <--    183  <--    183
               <--    200  <--      200
   ACK  -->   ACK  -->

My problem with last ACK, that I send to provider. Provider ignores it, and sends me some OK packets. As resultI can notend session ( answer to BYE 481 - transaction does not exists). I think it is wrong ACK but can not undrtand where I do mistake.

Please help me to find it: 

My invite (with Auth creditans):

IP 10.0.1.18.5068 > my.provider.ip.5060: UDP, length 1606
E...]. .@..R
...6........N0TINVITE sip:[hidden email]:5060 SIP/2.0
Record-Route: <sip:my.external.ip:5068;nat=yes;ftag=as7d06fc50;lr=on>
Via: SIP/2.0/UDP my.external.ip:5068;branch=z9hG4bK48ba.74ed5eb56b172cd802c50dcc201cce56.1
Via: SIP/2.0/UDP 10.0.1.6:50600;branch=z9hG4bK258b5220;rport=50600
Max-Forwards: 70
From: "John" <sip:[hidden email]>;tag=as7d06fc50
To: <sip:[hidden email]:5068>
Contact:<[hidden email]:5068>
CSeq: 102 INVITE
User-Agent: Asterisk PBX 12.5.0
Date: Wed, 27 Aug 2014 22:02:58 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 544
Proxy-Authorization: Digest username="provider_username", realm="my.provider.ip", nonce="U/5Wv1P+VZNjFBLf6fwPizgd6iLto5St", uri="sip:[hidden email]:5060", qop=auth, nc=00000001, cnonce="2888860875", response="9f23110471fe9ff751cd55466e70ded2", algorithm=MD5

v=0
o=root 1370647246 1370647246 IN IP4 12.34.56.78
s=Asterisk PBX 12.5.0
c=IN IP4 12.34.56.78
t=0 0
a=ice-lite
m=audio 30296 RTP/AVP 0 3 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv
a=rtcp:30297
a=ice-ufrag:p5k92ynl
a=ice-pwd:FIOYKt96NlBfEqKsQipUuadUev1g
a=candidate:vV3V06Tv



Provider trying


IP my.provider.ip.5060 > 10.0.1.18.5068: UDP, length 500
E.........PX6...
..........ySIP/2.0 100 trying -- your call is important to us
Via: SIP/2.0/UDP my.external.ip:5068;branch=z9hG4bK48ba.74ed5eb56b172cd802c50dcc201cce56.1;rport=5068;received=12.34.56.78
Via: SIP/2.0/UDP 10.0.1.6:50600;branch=z9hG4bK258b5220;rport=50600
From: "John" <sip:[hidden email]>;tag=as7d06fc50
To: <sip:[hidden email]:5068>
CSeq: 102 INVITE
Server: kamailio (4.1.2 (x86_64/linux))
Content-Length: 0




provider ringing




IP my.provider.ip.5060 > 10.0.1.18.5068: UDP, length 1098
E..f......M.6...
........RV.SIP/2.0 180 Ringing
Via: SIP/2.0/UDP my.external.ip:5068;rport=5068;received=12.34.56.78;branch=z9hG4bK48ba.74ed5eb56b172cd802c50dcc201cce56.1
Via: SIP/2.0/UDP 10.0.1.6:50600;branch=z9hG4bK258b5220;rport=50600
Record-Route: <sip:my.provider.ip;lr=on;ftag=as7d06fc50;did=5bc.33f1>
Record-Route: <sip:my.external.ip:5068;nat=yes;ftag=as7d06fc50;lr=on>
From: "John" <sip:[hidden email]>;tag=as7d06fc50
To: <sip:[hidden email]:5068>;tag=v9g4HD4vrNFUH
CSeq: 102 INVITE
Contact: <sip:12345678900@67.192.253.160:5060;transport=udp>
User-Agent: Plivo
Accept: application/sdp
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, precondition, path, replaces
Allow-Events: talk, hold, conference, presence, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer
Content-Length: 0
Remote-Party-ID: "12345678900" <sip:[hidden email]>;party=calling;privacy=off;screen=no



provider seesion in progress



IP my.provider.ip.5060 > 10.0.1.18.5068: UDP, length 1887
E..... ...,.6...
........g.DSIP/2.0 183 Session Progress
Via: SIP/2.0/UDP my.external.ip:5068;rport=5068;received=12.34.56.78;branch=z9hG4bK48ba.74ed5eb56b172cd802c50dcc201cce56.1
Via: SIP/2.0/UDP 10.0.1.6:50600;branch=z9hG4bK258b5220;rport=50600
Record-Route: <sip:my.provider.ip;lr=on;ftag=as7d06fc50;did=5bc.33f1>
Record-Route: <sip:my.external.ip:5068;nat=yes;ftag=as7d06fc50;lr=on>
From: "John" <sip:[hidden email]>;tag=as7d06fc50
To: <sip:[hidden email]:5068>;tag=v9g4HD4vrNFUH
CSeq: 102 INVITE
Contact: <sip:12345678900@67.192.253.160:5060;transport=udp>
User-Agent: Plivo
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, precondition, path, replaces
Allow-Events: talk, hold, conference, presence, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 742
Remote-Party-ID: "12345678900" <sip:[hidden email]>;party=calling;privacy=off;screen=no

v=0
o=FreeSWITCH 1409149800 1409149801 IN IP4 67.192.253.160
s=FreeSWITCH
c=IN IP4 67.192.253.160
t=0 0
a=msid-semantic: WMS uIWGGSqM8mUp5NEgQ9CU0svyzqjzisqD
m=audio 27180 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=ssrc:326362635 cnam




provider OK



IP my.provider.ip.5060 > 10.0.1.18.5068: UDP, length 2026
E..... ...,.6...
...........SIP/2.0 200 OK
Via: SIP/2.0/UDP my.external.ip:5068;rport=5068;received=12.34.56.78;branch=z9hG4bK48ba.74ed5eb56b172cd802c50dcc201cce56.1
Via: SIP/2.0/UDP 10.0.1.6:50600;branch=z9hG4bK258b5220;rport=50600
Record-Route: <sip:my.provider.ip;lr=on;ftag=as7d06fc50;did=5bc.33f1>
Record-Route: <sip:my.external.ip:5068;nat=yes;ftag=as7d06fc50;lr=on>
Fл2rom: "John" <sip:[hidden email]>;tag=as7d06fc50
To: <sip:[hidden email]:5068>;tag=v9g4HD4vrNFUH
CSeq: 102 INVITE
Contact: <sip:12345678900@67.192.253.160:5060;transport=udp>
User-Agent: Plivo
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REFER, NOTIFY, PUBLISH, SUBSCRIBE
SupлЛ
o=FreeSWITCH 1409149800 1409149801 IN IP4 67.192.253.160
s=FreeSWITCH
c=л2IN IP4 67.192.253.160
t=0 0
a=msid-semantic: WMS uIWGGSqM8mUp5NEgQ9CU0svyzqjzisqD
m=audio 27180 RTP/AVP 0




my ACK




IP 10.0.1.18.5068 > my.provider.ip.5060: UDP, length 614
E...]...@...
...6........n.hACK sip:[hidden email]:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP my.external.ip:5068;branch=z9hG4bK48ba.4250e4d315c4aa6697b6d7f70e861b62.0
Via: SIP/2.0/UDP 10.0.1.6:50600;branch=z9hG4bK4d28fc11;rport=50600
Route: <sip:my.provider.ip;lr=on;ftag=as7d06fc50;did=5bc.33f1>
Max-Forwards: 70
From: "John" <sip:[hidden email]>;tag=as7d06fc50
To: <sip:[hidden email]:5068>;tag=v9g4HD4vrNFUH
Contact:<[hidden email]:5068>
CSeq: 102 ACK
User-Agent: Asterisk PBX 12.5.0
Content-Length: 0



So after this ACK provider still sends me 200 OK and my server still sends ACK....

tags and call-id always one.


Thanks 

_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Reply | Threaded
Open this post in threaded view
|

Re: Wrong ACK to Provider

Olle E. Johansson

On 28 Aug 2014, at 14:14, Yuriy Gorlichenko <[hidden email]> wrote:

Hello. I try to provide call scheme:

internal client  -> asterisk -> Kamailio -> provider -> external endpoint call

when I make call I see this:

asterisk     kamailio   provider
invite -->       invite -->   
                                <--     407
                       ACK   -->    
                       invite w/Auth -->
              <--    100  <--    100
              <--    180  <--    180
              <--    183  <--    183
               <--    200  <--      200
   ACK  -->   ACK  -->

My problem with last ACK, that I send to provider. Provider ignores it, and sends me some OK packets. As resultI can notend session ( answer to BYE 481 - transaction does not exists). I think it is wrong ACK but can not undrtand where I do mistake.
Well, by letting the proxy handle authentication the INVITE tranction i closed without Asterisk knowing about it. So the ACK sent from the proxy and from Asterisk is for the same transaction, which messes things up. Asterisk does not know anything about the second invite. Letting the proxy handle authentiction breaks the SIP protocol in bad ways and is generally not a good solution.
You may want to send another response to asterisk when you get the 407 so Asterisk retries and use the retry as a trigger for the second INVITE and add auth to that.

/O

Please help me to find it: 

My invite (with Auth creditans):

IP 10.0.1.18.5068 > my.provider.ip.5060: UDP, length 1606
E...]. .@..R
...6........N0TINVITE <a href="sip:12345678900@my.provider.ip:5060">sip:12345678900@...:5060 SIP/2.0
Record-Route: <<a href="sip:my.external.ip:5068;nat=yes;ftag=as7d06fc50;lr=on">sip:my.external.ip:5068;nat=yes;ftag=as7d06fc50;lr=on>
Via: SIP/2.0/UDP my.external.ip:5068;branch=z9hG4bK48ba.74ed5eb56b172cd802c50dcc201cce56.1
Via: SIP/2.0/UDP 10.0.1.6:50600;branch=z9hG4bK258b5220;rport=50600
Max-Forwards: 70
From: "John" <<a href="sip:provider_username@my.provider.ip">sip:provider_username@...>;tag=as7d06fc50
To: <<a href="sip:12345678900@my.provider.ip:5068">sip:12345678900@...:5068>
Contact:<[hidden email]:5068>
CSeq: 102 INVITE
User-Agent: Asterisk PBX 12.5.0
Date: Wed, 27 Aug 2014 22:02:58 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 544
Proxy-Authorization: Digest username="provider_username", realm="my.provider.ip", nonce="U/5Wv1P+VZNjFBLf6fwPizgd6iLto5St", uri="<a href="sip:12345678900@my.provider.ip:5060">sip:12345678900@...:5060", qop=auth, nc=00000001, cnonce="2888860875", response="9f23110471fe9ff751cd55466e70ded2", algorithm=MD5

v=0
o=root 1370647246 1370647246 IN IP4 12.34.56.78
s=Asterisk PBX 12.5.0
c=IN IP4 12.34.56.78
t=0 0
a=ice-lite
m=audio 30296 RTP/AVP 0 3 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv
a=rtcp:30297
a=ice-ufrag:p5k92ynl
a=ice-pwd:FIOYKt96NlBfEqKsQipUuadUev1g
a=candidate:vV3V06Tv



Provider trying


IP my.provider.ip.5060 > 10.0.1.18.5068: UDP, length 500
E.........PX6...
..........ySIP/2.0 100 trying -- your call is important to us
Via: SIP/2.0/UDP my.external.ip:5068;branch=z9hG4bK48ba.74ed5eb56b172cd802c50dcc201cce56.1;rport=5068;received=12.34.56.78
Via: SIP/2.0/UDP 10.0.1.6:50600;branch=z9hG4bK258b5220;rport=50600
From: "John" <<a href="sip:provider_username@my.provider.ip">sip:provider_username@...>;tag=as7d06fc50
To: <<a href="sip:12345678900@my.provider.ip:5068">sip:12345678900@...:5068>
CSeq: 102 INVITE
Server: kamailio (4.1.2 (x86_64/linux))
Content-Length: 0




provider ringing




IP my.provider.ip.5060 > 10.0.1.18.5068: UDP, length 1098
E..f......M.6...
........RV.SIP/2.0 180 Ringing
Via: SIP/2.0/UDP my.external.ip:5068;rport=5068;received=12.34.56.78;branch=z9hG4bK48ba.74ed5eb56b172cd802c50dcc201cce56.1
Via: SIP/2.0/UDP 10.0.1.6:50600;branch=z9hG4bK258b5220;rport=50600
Record-Route: <<a href="sip:my.provider.ip;lr=on;ftag=as7d06fc50;did=5bc.33f1">sip:my.provider.ip;lr=on;ftag=as7d06fc50;did=5bc.33f1>
Record-Route: <<a href="sip:my.external.ip:5068;nat=yes;ftag=as7d06fc50;lr=on">sip:my.external.ip:5068;nat=yes;ftag=as7d06fc50;lr=on>
From: "John" <<a href="sip:provider_username@my.provider.ip">sip:provider_username@...>;tag=as7d06fc50
To: <<a href="sip:12345678900@my.provider.ip:5068">sip:12345678900@...:5068>;tag=v9g4HD4vrNFUH
CSeq: 102 INVITE
Contact: <<a href="sip:12345678900@67.192.253.160:5060;transport=udp">sip:12345678900@67.192.253.160:5060;transport=udp>
User-Agent: Plivo
Accept: application/sdp
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, precondition, path, replaces
Allow-Events: talk, hold, conference, presence, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer
Content-Length: 0
Remote-Party-ID: "12345678900" <<a href="sip:12345678900@my.provider.ip">sip:12345678900@...>;party=calling;privacy=off;screen=no



provider seesion in progress



IP my.provider.ip.5060 > 10.0.1.18.5068: UDP, length 1887
E..... ...,.6...
........g.DSIP/2.0 183 Session Progress
Via: SIP/2.0/UDP my.external.ip:5068;rport=5068;received=12.34.56.78;branch=z9hG4bK48ba.74ed5eb56b172cd802c50dcc201cce56.1
Via: SIP/2.0/UDP 10.0.1.6:50600;branch=z9hG4bK258b5220;rport=50600
Record-Route: <<a href="sip:my.provider.ip;lr=on;ftag=as7d06fc50;did=5bc.33f1">sip:my.provider.ip;lr=on;ftag=as7d06fc50;did=5bc.33f1>
Record-Route: <<a href="sip:my.external.ip:5068;nat=yes;ftag=as7d06fc50;lr=on">sip:my.external.ip:5068;nat=yes;ftag=as7d06fc50;lr=on>
From: "John" <<a href="sip:provider_username@my.provider.ip">sip:provider_username@...>;tag=as7d06fc50
To: <<a href="sip:12345678900@my.provider.ip:5068">sip:12345678900@...:5068>;tag=v9g4HD4vrNFUH
CSeq: 102 INVITE
Contact: <<a href="sip:12345678900@67.192.253.160:5060;transport=udp">sip:12345678900@67.192.253.160:5060;transport=udp>
User-Agent: Plivo
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, precondition, path, replaces
Allow-Events: talk, hold, conference, presence, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 742
Remote-Party-ID: "12345678900" <<a href="sip:12345678900@my.provider.ip">sip:12345678900@...>;party=calling;privacy=off;screen=no

v=0
o=FreeSWITCH 1409149800 1409149801 IN IP4 67.192.253.160
s=FreeSWITCH
c=IN IP4 67.192.253.160
t=0 0
a=msid-semantic: WMS uIWGGSqM8mUp5NEgQ9CU0svyzqjzisqD
m=audio 27180 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=ssrc:326362635 cnam




provider OK



IP my.provider.ip.5060 > 10.0.1.18.5068: UDP, length 2026
E..... ...,.6...
...........SIP/2.0 200 OK
Via: SIP/2.0/UDP my.external.ip:5068;rport=5068;received=12.34.56.78;branch=z9hG4bK48ba.74ed5eb56b172cd802c50dcc201cce56.1
Via: SIP/2.0/UDP 10.0.1.6:50600;branch=z9hG4bK258b5220;rport=50600
Record-Route: <<a href="sip:my.provider.ip;lr=on;ftag=as7d06fc50;did=5bc.33f1">sip:my.provider.ip;lr=on;ftag=as7d06fc50;did=5bc.33f1>
Record-Route: <<a href="sip:my.external.ip:5068;nat=yes;ftag=as7d06fc50;lr=on">sip:my.external.ip:5068;nat=yes;ftag=as7d06fc50;lr=on>
Fл2rom: "John" <<a href="sip:provider_username@my.provider.ip">sip:provider_username@...>;tag=as7d06fc50
To: <<a href="sip:12345678900@my.provider.ip:5068">sip:12345678900@...:5068>;tag=v9g4HD4vrNFUH
CSeq: 102 INVITE
Contact: <<a href="sip:12345678900@67.192.253.160:5060;transport=udp">sip:12345678900@67.192.253.160:5060;transport=udp>
User-Agent: Plivo
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REFER, NOTIFY, PUBLISH, SUBSCRIBE
SupлЛ
o=FreeSWITCH 1409149800 1409149801 IN IP4 67.192.253.160
s=FreeSWITCH
c=л2IN IP4 67.192.253.160
t=0 0
a=msid-semantic: WMS uIWGGSqM8mUp5NEgQ9CU0svyzqjzisqD
m=audio 27180 RTP/AVP 0




my ACK




IP 10.0.1.18.5068 > my.provider.ip.5060: UDP, length 614
E...]...@...
...6........n.hACK <a href="sip:12345678900@my.provider.ip:5060;transport=udp">sip:12345678900@...:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP my.external.ip:5068;branch=z9hG4bK48ba.4250e4d315c4aa6697b6d7f70e861b62.0
Via: SIP/2.0/UDP 10.0.1.6:50600;branch=z9hG4bK4d28fc11;rport=50600
Route: <<a href="sip:my.provider.ip;lr=on;ftag=as7d06fc50;did=5bc.33f1">sip:my.provider.ip;lr=on;ftag=as7d06fc50;did=5bc.33f1>
Max-Forwards: 70
From: "John" <<a href="sip:provider_username@my.provider.ip">sip:provider_username@...>;tag=as7d06fc50
To: <<a href="sip:12345678900@my.provider.ip:5068">sip:12345678900@...:5068>;tag=v9g4HD4vrNFUH
Contact:<[hidden email]:5068>
CSeq: 102 ACK
User-Agent: Asterisk PBX 12.5.0
Content-Length: 0



So after this ACK provider still sends me 200 OK and my server still sends ACK....

tags and call-id always one.


Thanks 
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Reply | Threaded
Open this post in threaded view
|

Re: Wrong ACK to Provider

Daniel-Constantin Mierla-6

On 28/08/14 14:45, Olle E. Johansson wrote:

On 28 Aug 2014, at 14:14, Yuriy Gorlichenko <[hidden email]> wrote:

Hello. I try to provide call scheme:

internal client  -> asterisk -> Kamailio -> provider -> external endpoint call

when I make call I see this:

asterisk     kamailio   provider
invite -->       invite -->   
                                <--     407
                       ACK   -->    
                       invite w/Auth -->
              <--    100  <--    100
              <--    180  <--    180
              <--    183  <--    183
               <--    200  <--      200
   ACK  -->   ACK  -->

My problem with last ACK, that I send to provider. Provider ignores it, and sends me some OK packets. As resultI can notend session ( answer to BYE 481 - transaction does not exists). I think it is wrong ACK but can not undrtand where I do mistake.
Well, by letting the proxy handle authentication the INVITE tranction i closed without Asterisk knowing about it. So the ACK sent from the proxy and from Asterisk is for the same transaction, which messes things up. Asterisk does not know anything about the second invite. Letting the proxy handle authentiction breaks the SIP protocol in bad ways and is generally not a good solution.
You may want to send another response to asterisk when you get the 407 so Asterisk retries and use the retry as a trigger for the second INVITE and add auth to that.
While breaking the cseq incrementation for authentication (mentioned in the readme of uac), the Asterisk seems to do ok here, because the ACK is coming from asterisk, but it is not accepted by the provider.

The provider (having a plivo platform, based on the responses) is running kamailio 4.1.2 in front (looking at 100 trying).

Authentication from kamailio to another kamailio using uac module should work fine, as kamailio doesn't act as end user UAC and doesn't care much of cseq.

I didn't have time to look at the sip trace properly, but Asterisk should have nothing to do with the problem here, unless I missed something from the description.

Cheers,
Daniel


-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Next Kamailio Advanced Trainings 2014 - http://www.asipto.com
Sep 22-25, Berlin, Germany ::: Oct 15-17, San Francisco, USA

_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Reply | Threaded
Open this post in threaded view
|

Re: Wrong ACK to Provider

Yuriy Gorlichenko
All packets (INVITE,ACK,BYE) that comes from Asterisk and sends to Provider handled by Kamailio (changed tU, fU and td and from d). so I write to PLIVO this question, but they still answer to me  nothing... As I see my trace there are no simple muistakes (such as wrong dst or wrong contact header).

AboutAsteirsk and Kamailio I think As Daniel that Auth is not Asterisk problem. 
Furthermore Asterisk works with kamailio without registration on kamailio: ip-based dialog.

So Daniel - If you will have some time to see my trace I will be happy.

Thanks for answers and help.

I will thinkabout problem to and waiting answer.




2014-08-28 16:57 GMT+04:00 Daniel-Constantin Mierla <[hidden email]>:

On 28/08/14 14:45, Olle E. Johansson wrote:

On 28 Aug 2014, at 14:14, Yuriy Gorlichenko <[hidden email]> wrote:

Hello. I try to provide call scheme:

internal client  -> asterisk -> Kamailio -> provider -> external endpoint call

when I make call I see this:

asterisk     kamailio   provider
invite -->       invite -->   
                                <--     407
                       ACK   -->    
                       invite w/Auth -->
              <--    100  <--    100
              <--    180  <--    180
              <--    183  <--    183
               <--    200  <--      200
   ACK  -->   ACK  -->

My problem with last ACK, that I send to provider. Provider ignores it, and sends me some OK packets. As resultI can notend session ( answer to BYE 481 - transaction does not exists). I think it is wrong ACK but can not undrtand where I do mistake.
Well, by letting the proxy handle authentication the INVITE tranction i closed without Asterisk knowing about it. So the ACK sent from the proxy and from Asterisk is for the same transaction, which messes things up. Asterisk does not know anything about the second invite. Letting the proxy handle authentiction breaks the SIP protocol in bad ways and is generally not a good solution.
You may want to send another response to asterisk when you get the 407 so Asterisk retries and use the retry as a trigger for the second INVITE and add auth to that.
While breaking the cseq incrementation for authentication (mentioned in the readme of uac), the Asterisk seems to do ok here, because the ACK is coming from asterisk, but it is not accepted by the provider.

The provider (having a plivo platform, based on the responses) is running kamailio 4.1.2 in front (looking at 100 trying).

Authentication from kamailio to another kamailio using uac module should work fine, as kamailio doesn't act as end user UAC and doesn't care much of cseq.

I didn't have time to look at the sip trace properly, but Asterisk should have nothing to do with the problem here, unless I missed something from the description.

Cheers,
Daniel


-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Next Kamailio Advanced Trainings 2014 - http://www.asipto.com
Sep 22-25, Berlin, Germany ::: Oct 15-17, San Francisco, USA

_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users



_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Reply | Threaded
Open this post in threaded view
|

Re: Wrong ACK to Provider

Olle E. Johansson
In reply to this post by Daniel-Constantin Mierla-6

On 28 Aug 2014, at 14:57, Daniel-Constantin Mierla <[hidden email]> wrote:


On 28/08/14 14:45, Olle E. Johansson wrote:

On 28 Aug 2014, at 14:14, Yuriy Gorlichenko <[hidden email]> wrote:

Hello. I try to provide call scheme:

internal client  -> asterisk -> Kamailio -> provider -> external endpoint call

when I make call I see this:

asterisk     kamailio   provider
invite -->       invite -->   
                                <--     407
                       ACK   -->    
                       invite w/Auth -->
              <--    100  <--    100
              <--    180  <--    180
              <--    183  <--    183
               <--    200  <--      200
   ACK  -->   ACK  -->

My problem with last ACK, that I send to provider. Provider ignores it, and sends me some OK packets. As resultI can notend session ( answer to BYE 481 - transaction does not exists). I think it is wrong ACK but can not undrtand where I do mistake.
Well, by letting the proxy handle authentication the INVITE tranction i closed without Asterisk knowing about it. So the ACK sent from the proxy and from Asterisk is for the same transaction, which messes things up. Asterisk does not know anything about the second invite. Letting the proxy handle authentiction breaks the SIP protocol in bad ways and is generally not a good solution.
You may want to send another response to asterisk when you get the 407 so Asterisk retries and use the retry as a trigger for the second INVITE and add auth to that.
While breaking the cseq incrementation for authentication (mentioned in the readme of uac), the Asterisk seems to do ok here, because the ACK is coming from asterisk, but it is not accepted by the provider.
You are missing the fact that the ACK sent by Asterisk is already sent by the proxy. The INVITE w/AUth have a different cseq than the ACK. 

The provider (having a plivo platform, based on the responses) is running kamailio 4.1.2 in front (looking at 100 trying).

Authentication from kamailio to another kamailio using uac module should work fine, as kamailio doesn't act as end user UAC and doesn't care much of cseq.
Won't the second ACK on the same transaction just be ignored, while it waits for an ACK on the new transaction?

I didn't have time to look at the sip trace properly, but Asterisk should have nothing to do with the problem here, unless I missed something from the description.

/O

Cheers,
Daniel


-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Next Kamailio Advanced Trainings 2014 - http://www.asipto.com
Sep 22-25, Berlin, Germany ::: Oct 15-17, San Francisco, USA
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Reply | Threaded
Open this post in threaded view
|

Re: Wrong ACK to Provider

Daniel-Constantin Mierla-6
In reply to this post by Yuriy Gorlichenko
You should send a pcap file with all packets, from first incoming INVITE to kamailio. It is important to have both sides of signaling from kamailio point of view, from first packet in that call.

Cheers,
Daniel

On 28/08/14 15:11, Yuriy Gorlichenko wrote:
All packets (INVITE,ACK,BYE) that comes from Asterisk and sends to Provider handled by Kamailio (changed tU, fU and td and from d). so I write to PLIVO this question, but they still answer to me  nothing... As I see my trace there are no simple muistakes (such as wrong dst or wrong contact header).

AboutAsteirsk and Kamailio I think As Daniel that Auth is not Asterisk problem. 
Furthermore Asterisk works with kamailio without registration on kamailio: ip-based dialog.

So Daniel - If you will have some time to see my trace I will be happy.

Thanks for answers and help.

I will thinkabout problem to and waiting answer.





2014-08-28 16:57 GMT+04:00 Daniel-Constantin Mierla <[hidden email]>:

On 28/08/14 14:45, Olle E. Johansson wrote:

On 28 Aug 2014, at 14:14, Yuriy Gorlichenko <[hidden email]> wrote:

Hello. I try to provide call scheme:

internal client  -> asterisk -> Kamailio -> provider -> external endpoint call

when I make call I see this:

asterisk     kamailio   provider
invite -->       invite -->   
                                <--     407
                       ACK   -->    
                       invite w/Auth -->
              <--    100  <--    100
              <--    180  <--    180
              <--    183  <--    183
               <--    200  <--      200
   ACK  -->   ACK  -->

My problem with last ACK, that I send to provider. Provider ignores it, and sends me some OK packets. As resultI can notend session ( answer to BYE 481 - transaction does not exists). I think it is wrong ACK but can not undrtand where I do mistake.
Well, by letting the proxy handle authentication the INVITE tranction i closed without Asterisk knowing about it. So the ACK sent from the proxy and from Asterisk is for the same transaction, which messes things up. Asterisk does not know anything about the second invite. Letting the proxy handle authentiction breaks the SIP protocol in bad ways and is generally not a good solution.
You may want to send another response to asterisk when you get the 407 so Asterisk retries and use the retry as a trigger for the second INVITE and add auth to that.
While breaking the cseq incrementation for authentication (mentioned in the readme of uac), the Asterisk seems to do ok here, because the ACK is coming from asterisk, but it is not accepted by the provider.

The provider (having a plivo platform, based on the responses) is running kamailio 4.1.2 in front (looking at 100 trying).

Authentication from kamailio to another kamailio using uac module should work fine, as kamailio doesn't act as end user UAC and doesn't care much of cseq.

I didn't have time to look at the sip trace properly, but Asterisk should have nothing to do with the problem here, unless I missed something from the description.

Cheers,
Daniel


-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Next Kamailio Advanced Trainings 2014 - http://www.asipto.com
Sep 22-25, Berlin, Germany ::: Oct 15-17, San Francisco, USA

_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users



-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Next Kamailio Advanced Trainings 2014 - http://www.asipto.com
Sep 22-25, Berlin, Germany ::: Oct 15-17, San Francisco, USA

_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Reply | Threaded
Open this post in threaded view
|

Re: Wrong ACK to Provider

Daniel-Constantin Mierla-6
In reply to this post by Olle E. Johansson

On 28/08/14 15:11, Olle E. Johansson wrote:

On 28 Aug 2014, at 14:57, Daniel-Constantin Mierla <[hidden email]> wrote:


On 28/08/14 14:45, Olle E. Johansson wrote:

On 28 Aug 2014, at 14:14, Yuriy Gorlichenko <[hidden email]> wrote:

Hello. I try to provide call scheme:

internal client  -> asterisk -> Kamailio -> provider -> external endpoint call

when I make call I see this:

asterisk     kamailio   provider
invite -->       invite -->   
                                <--     407
                       ACK   -->    
                       invite w/Auth -->
              <--    100  <--    100
              <--    180  <--    180
              <--    183  <--    183
               <--    200  <--      200
   ACK  -->   ACK  -->

My problem with last ACK, that I send to provider. Provider ignores it, and sends me some OK packets. As resultI can notend session ( answer to BYE 481 - transaction does not exists). I think it is wrong ACK but can not undrtand where I do mistake.
Well, by letting the proxy handle authentication the INVITE tranction i closed without Asterisk knowing about it. So the ACK sent from the proxy and from Asterisk is for the same transaction, which messes things up. Asterisk does not know anything about the second invite. Letting the proxy handle authentiction breaks the SIP protocol in bad ways and is generally not a good solution.
You may want to send another response to asterisk when you get the 407 so Asterisk retries and use the retry as a trigger for the second INVITE and add auth to that.
While breaking the cseq incrementation for authentication (mentioned in the readme of uac), the Asterisk seems to do ok here, because the ACK is coming from asterisk, but it is not accepted by the provider.
You are missing the fact that the ACK sent by Asterisk is already sent by the proxy. The INVITE w/AUth have a different cseq than the ACK.
Kamailio is doing serial forking in this case, so the first ack is for the first branch that gets 407. This should be as usual for serial/parallel forking.

Then, Kamailio is not increasing the cseq here -- that's the limitation with uac auth module, because the authenticator should normally reject it. But if it is authentication against another kamailio, should just work.


The provider (having a plivo platform, based on the responses) is running kamailio 4.1.2 in front (looking at 100 trying).

Authentication from kamailio to another kamailio using uac module should work fine, as kamailio doesn't act as end user UAC and doesn't care much of cseq.
Won't the second ACK on the same transaction just be ignored, while it waits for an ACK on the new transaction?
It is the same transaction in this case, just two branches from kamailio downstream, which is serial forking case, as mentioned above.

Cheers,
Daniel

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Next Kamailio Advanced Trainings 2014 - http://www.asipto.com
Sep 22-25, Berlin, Germany ::: Oct 15-17, San Francisco, USA

_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Reply | Threaded
Open this post in threaded view
|

Re: Wrong ACK to Provider

Yuriy Gorlichenko
My pcap file. Daniel sorry for first time sended message to your private mail. Was a mistake.  


2014-08-28 17:27 GMT+04:00 Daniel-Constantin Mierla <[hidden email]>:

On 28/08/14 15:11, Olle E. Johansson wrote:

On 28 Aug 2014, at 14:57, Daniel-Constantin Mierla <[hidden email]> wrote:


On 28/08/14 14:45, Olle E. Johansson wrote:

On 28 Aug 2014, at 14:14, Yuriy Gorlichenko <[hidden email]> wrote:

Hello. I try to provide call scheme:

internal client  -> asterisk -> Kamailio -> provider -> external endpoint call

when I make call I see this:

asterisk     kamailio   provider
invite -->       invite -->   
                                <--     407
                       ACK   -->    
                       invite w/Auth -->
              <--    100  <--    100
              <--    180  <--    180
              <--    183  <--    183
               <--    200  <--      200
   ACK  -->   ACK  -->

My problem with last ACK, that I send to provider. Provider ignores it, and sends me some OK packets. As resultI can notend session ( answer to BYE 481 - transaction does not exists). I think it is wrong ACK but can not undrtand where I do mistake.
Well, by letting the proxy handle authentication the INVITE tranction i closed without Asterisk knowing about it. So the ACK sent from the proxy and from Asterisk is for the same transaction, which messes things up. Asterisk does not know anything about the second invite. Letting the proxy handle authentiction breaks the SIP protocol in bad ways and is generally not a good solution.
You may want to send another response to asterisk when you get the 407 so Asterisk retries and use the retry as a trigger for the second INVITE and add auth to that.
While breaking the cseq incrementation for authentication (mentioned in the readme of uac), the Asterisk seems to do ok here, because the ACK is coming from asterisk, but it is not accepted by the provider.
You are missing the fact that the ACK sent by Asterisk is already sent by the proxy. The INVITE w/AUth have a different cseq than the ACK.
Kamailio is doing serial forking in this case, so the first ack is for the first branch that gets 407. This should be as usual for serial/parallel forking.

Then, Kamailio is not increasing the cseq here -- that's the limitation with uac auth module, because the authenticator should normally reject it. But if it is authentication against another kamailio, should just work.



The provider (having a plivo platform, based on the responses) is running kamailio 4.1.2 in front (looking at 100 trying).

Authentication from kamailio to another kamailio using uac module should work fine, as kamailio doesn't act as end user UAC and doesn't care much of cseq.
Won't the second ACK on the same transaction just be ignored, while it waits for an ACK on the new transaction?
It is the same transaction in this case, just two branches from kamailio downstream, which is serial forking case, as mentioned above.


Cheers,
Daniel

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Next Kamailio Advanced Trainings 2014 - http://www.asipto.com
Sep 22-25, Berlin, Germany ::: Oct 15-17, San Francisco, USA

_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users



_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

mydump1.pcap (79K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Wrong ACK to Provider

Daniel-Constantin Mierla-6
I don't mind to receive directly attachments that can contain sensitive data. But you have to write an email via mailing list saying you do/did so.

With gmail I am checking mostly the emails that are filtered with various rules, otherwise, the rest land together with a lot of spam/advertising and check them very rarely, if ever.

So, as a reminder to anyone that did it -- if a conversation from mailing list was turned into a direct email to me only, it very unlikely to get answered soon, given the load I have -- better resend to mailing list.

I had no time to look yet at the trace.

Cheers,
Daniel

On 29/08/14 07:08, Yuriy Gorlichenko wrote:
My pcap file. Daniel sorry for first time sended message to your private mail. Was a mistake.  


2014-08-28 17:27 GMT+04:00 Daniel-Constantin Mierla <[hidden email]>:

On 28/08/14 15:11, Olle E. Johansson wrote:

On 28 Aug 2014, at 14:57, Daniel-Constantin Mierla <[hidden email]> wrote:


On 28/08/14 14:45, Olle E. Johansson wrote:

On 28 Aug 2014, at 14:14, Yuriy Gorlichenko <[hidden email]> wrote:

Hello. I try to provide call scheme:

internal client  -> asterisk -> Kamailio -> provider -> external endpoint call

when I make call I see this:

asterisk     kamailio   provider
invite -->       invite -->   
                                <--     407
                       ACK   -->    
                       invite w/Auth -->
              <--    100  <--    100
              <--    180  <--    180
              <--    183  <--    183
               <--    200  <--      200
   ACK  -->   ACK  -->

My problem with last ACK, that I send to provider. Provider ignores it, and sends me some OK packets. As resultI can notend session ( answer to BYE 481 - transaction does not exists). I think it is wrong ACK but can not undrtand where I do mistake.
Well, by letting the proxy handle authentication the INVITE tranction i closed without Asterisk knowing about it. So the ACK sent from the proxy and from Asterisk is for the same transaction, which messes things up. Asterisk does not know anything about the second invite. Letting the proxy handle authentiction breaks the SIP protocol in bad ways and is generally not a good solution.
You may want to send another response to asterisk when you get the 407 so Asterisk retries and use the retry as a trigger for the second INVITE and add auth to that.
While breaking the cseq incrementation for authentication (mentioned in the readme of uac), the Asterisk seems to do ok here, because the ACK is coming from asterisk, but it is not accepted by the provider.
You are missing the fact that the ACK sent by Asterisk is already sent by the proxy. The INVITE w/AUth have a different cseq than the ACK.
Kamailio is doing serial forking in this case, so the first ack is for the first branch that gets 407. This should be as usual for serial/parallel forking.

Then, Kamailio is not increasing the cseq here -- that's the limitation with uac auth module, because the authenticator should normally reject it. But if it is authentication against another kamailio, should just work.



The provider (having a plivo platform, based on the responses) is running kamailio 4.1.2 in front (looking at 100 trying).

Authentication from kamailio to another kamailio using uac module should work fine, as kamailio doesn't act as end user UAC and doesn't care much of cseq.
Won't the second ACK on the same transaction just be ignored, while it waits for an ACK on the new transaction?
It is the same transaction in this case, just two branches from kamailio downstream, which is serial forking case, as mentioned above.


Cheers,
Daniel

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Next Kamailio Advanced Trainings 2014 - http://www.asipto.com
Sep 22-25, Berlin, Germany ::: Oct 15-17, San Francisco, USA

_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users



-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Next Kamailio Advanced Trainings 2014 - http://www.asipto.com
Sep 22-25, Berlin, Germany ::: Oct 15-17, San Francisco, USA

_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Reply | Threaded
Open this post in threaded view
|

Re: Wrong ACK to Provider

Daniel-Constantin Mierla-6
In reply to this post by Yuriy Gorlichenko
Apparently the file got corrupted, most probably by email client/server encoding, and it shows only three packets.

Can you resend it compress as tgz?

Cheers,
Daniel

On 29/08/14 07:08, Yuriy Gorlichenko wrote:
My pcap file. Daniel sorry for first time sended message to your private mail. Was a mistake.  


2014-08-28 17:27 GMT+04:00 Daniel-Constantin Mierla <[hidden email]>:

On 28/08/14 15:11, Olle E. Johansson wrote:

On 28 Aug 2014, at 14:57, Daniel-Constantin Mierla <[hidden email]> wrote:


On 28/08/14 14:45, Olle E. Johansson wrote:

On 28 Aug 2014, at 14:14, Yuriy Gorlichenko <[hidden email]> wrote:

Hello. I try to provide call scheme:

internal client  -> asterisk -> Kamailio -> provider -> external endpoint call

when I make call I see this:

asterisk     kamailio   provider
invite -->       invite -->   
                                <--     407
                       ACK   -->    
                       invite w/Auth -->
              <--    100  <--    100
              <--    180  <--    180
              <--    183  <--    183
               <--    200  <--      200
   ACK  -->   ACK  -->

My problem with last ACK, that I send to provider. Provider ignores it, and sends me some OK packets. As resultI can notend session ( answer to BYE 481 - transaction does not exists). I think it is wrong ACK but can not undrtand where I do mistake.
Well, by letting the proxy handle authentication the INVITE tranction i closed without Asterisk knowing about it. So the ACK sent from the proxy and from Asterisk is for the same transaction, which messes things up. Asterisk does not know anything about the second invite. Letting the proxy handle authentiction breaks the SIP protocol in bad ways and is generally not a good solution.
You may want to send another response to asterisk when you get the 407 so Asterisk retries and use the retry as a trigger for the second INVITE and add auth to that.
While breaking the cseq incrementation for authentication (mentioned in the readme of uac), the Asterisk seems to do ok here, because the ACK is coming from asterisk, but it is not accepted by the provider.
You are missing the fact that the ACK sent by Asterisk is already sent by the proxy. The INVITE w/AUth have a different cseq than the ACK.
Kamailio is doing serial forking in this case, so the first ack is for the first branch that gets 407. This should be as usual for serial/parallel forking.

Then, Kamailio is not increasing the cseq here -- that's the limitation with uac auth module, because the authenticator should normally reject it. But if it is authentication against another kamailio, should just work.



The provider (having a plivo platform, based on the responses) is running kamailio 4.1.2 in front (looking at 100 trying).

Authentication from kamailio to another kamailio using uac module should work fine, as kamailio doesn't act as end user UAC and doesn't care much of cseq.
Won't the second ACK on the same transaction just be ignored, while it waits for an ACK on the new transaction?
It is the same transaction in this case, just two branches from kamailio downstream, which is serial forking case, as mentioned above.


Cheers,
Daniel

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Next Kamailio Advanced Trainings 2014 - http://www.asipto.com
Sep 22-25, Berlin, Germany ::: Oct 15-17, San Francisco, USA

_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users



-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Next Kamailio Advanced Trainings 2014 - http://www.asipto.com
Sep 22-25, Berlin, Germany ::: Oct 15-17, San Francisco, USA

_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Reply | Threaded
Open this post in threaded view
|

Re: Wrong ACK to Provider

Daniel-Constantin Mierla-6
In reply to this post by Daniel-Constantin Mierla-6
The last .zip file is also showing only 3 packets (different ones) -- can you check the trace has all the packet before you compress? Maybe you can put it somewhere on a server for download and send me the link, so I get it over http.

Cheers,
Daniel

On 29/08/14 09:36, Daniel-Constantin Mierla wrote:
I don't mind to receive directly attachments that can contain sensitive data. But you have to write an email via mailing list saying you do/did so.

With gmail I am checking mostly the emails that are filtered with various rules, otherwise, the rest land together with a lot of spam/advertising and check them very rarely, if ever.

So, as a reminder to anyone that did it -- if a conversation from mailing list was turned into a direct email to me only, it very unlikely to get answered soon, given the load I have -- better resend to mailing list.

I had no time to look yet at the trace.

Cheers,
Daniel

On 29/08/14 07:08, Yuriy Gorlichenko wrote:
My pcap file. Daniel sorry for first time sended message to your private mail. Was a mistake.  


2014-08-28 17:27 GMT+04:00 Daniel-Constantin Mierla <[hidden email]>:

On 28/08/14 15:11, Olle E. Johansson wrote:

On 28 Aug 2014, at 14:57, Daniel-Constantin Mierla <[hidden email]> wrote:


On 28/08/14 14:45, Olle E. Johansson wrote:

On 28 Aug 2014, at 14:14, Yuriy Gorlichenko <[hidden email]> wrote:

Hello. I try to provide call scheme:

internal client  -> asterisk -> Kamailio -> provider -> external endpoint call

when I make call I see this:

asterisk     kamailio   provider
invite -->       invite -->   
                                <--     407
                       ACK   -->    
                       invite w/Auth -->
              <--    100  <--    100
              <--    180  <--    180
              <--    183  <--    183
               <--    200  <--      200
   ACK  -->   ACK  -->

My problem with last ACK, that I send to provider. Provider ignores it, and sends me some OK packets. As resultI can notend session ( answer to BYE 481 - transaction does not exists). I think it is wrong ACK but can not undrtand where I do mistake.
Well, by letting the proxy handle authentication the INVITE tranction i closed without Asterisk knowing about it. So the ACK sent from the proxy and from Asterisk is for the same transaction, which messes things up. Asterisk does not know anything about the second invite. Letting the proxy handle authentiction breaks the SIP protocol in bad ways and is generally not a good solution.
You may want to send another response to asterisk when you get the 407 so Asterisk retries and use the retry as a trigger for the second INVITE and add auth to that.
While breaking the cseq incrementation for authentication (mentioned in the readme of uac), the Asterisk seems to do ok here, because the ACK is coming from asterisk, but it is not accepted by the provider.
You are missing the fact that the ACK sent by Asterisk is already sent by the proxy. The INVITE w/AUth have a different cseq than the ACK.
Kamailio is doing serial forking in this case, so the first ack is for the first branch that gets 407. This should be as usual for serial/parallel forking.

Then, Kamailio is not increasing the cseq here -- that's the limitation with uac auth module, because the authenticator should normally reject it. But if it is authentication against another kamailio, should just work.



The provider (having a plivo platform, based on the responses) is running kamailio 4.1.2 in front (looking at 100 trying).

Authentication from kamailio to another kamailio using uac module should work fine, as kamailio doesn't act as end user UAC and doesn't care much of cseq.
Won't the second ACK on the same transaction just be ignored, while it waits for an ACK on the new transaction?
It is the same transaction in this case, just two branches from kamailio downstream, which is serial forking case, as mentioned above.


Cheers,
Daniel

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Next Kamailio Advanced Trainings 2014 - http://www.asipto.com
Sep 22-25, Berlin, Germany ::: Oct 15-17, San Francisco, USA

_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users



-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Next Kamailio Advanced Trainings 2014 - http://www.asipto.com
Sep 22-25, Berlin, Germany ::: Oct 15-17, San Francisco, USA

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Next Kamailio Advanced Trainings 2014 - http://www.asipto.com
Sep 22-25, Berlin, Germany ::: Oct 15-17, San Francisco, USA

_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Reply | Threaded
Open this post in threaded view
|

Re: Wrong ACK to Provider

Daniel-Constantin Mierla-6
How did you grab the pcap? All the variants (including the zip via http download) are not recognized by ngrep or wireshark.

Anyhow, I looked with a text editor inside the and I could see that the ACK is changing the r-uri -- it comes to kamailio with the contact from 200ok, but goes out with a different hostname. You have some rules in kamailio.cfg that do that -- you should let the r-uri unchanged for ack -- routing is done via record-routing.

Cheers,
Daniel

On 29/08/14 16:12, Daniel-Constantin Mierla wrote:
The last .zip file is also showing only 3 packets (different ones) -- can you check the trace has all the packet before you compress? Maybe you can put it somewhere on a server for download and send me the link, so I get it over http.

Cheers,
Daniel

On 29/08/14 09:36, Daniel-Constantin Mierla wrote:
I don't mind to receive directly attachments that can contain sensitive data. But you have to write an email via mailing list saying you do/did so.

With gmail I am checking mostly the emails that are filtered with various rules, otherwise, the rest land together with a lot of spam/advertising and check them very rarely, if ever.

So, as a reminder to anyone that did it -- if a conversation from mailing list was turned into a direct email to me only, it very unlikely to get answered soon, given the load I have -- better resend to mailing list.

I had no time to look yet at the trace.

Cheers,
Daniel

On 29/08/14 07:08, Yuriy Gorlichenko wrote:
My pcap file. Daniel sorry for first time sended message to your private mail. Was a mistake.  


2014-08-28 17:27 GMT+04:00 Daniel-Constantin Mierla <[hidden email]>:

On 28/08/14 15:11, Olle E. Johansson wrote:

On 28 Aug 2014, at 14:57, Daniel-Constantin Mierla <[hidden email]> wrote:


On 28/08/14 14:45, Olle E. Johansson wrote:

On 28 Aug 2014, at 14:14, Yuriy Gorlichenko <[hidden email]> wrote:

Hello. I try to provide call scheme:

internal client  -> asterisk -> Kamailio -> provider -> external endpoint call

when I make call I see this:

asterisk     kamailio   provider
invite -->       invite -->   
                                <--     407
                       ACK   -->    
                       invite w/Auth -->
              <--    100  <--    100
              <--    180  <--    180
              <--    183  <--    183
               <--    200  <--      200
   ACK  -->   ACK  -->

My problem with last ACK, that I send to provider. Provider ignores it, and sends me some OK packets. As resultI can notend session ( answer to BYE 481 - transaction does not exists). I think it is wrong ACK but can not undrtand where I do mistake.
Well, by letting the proxy handle authentication the INVITE tranction i closed without Asterisk knowing about it. So the ACK sent from the proxy and from Asterisk is for the same transaction, which messes things up. Asterisk does not know anything about the second invite. Letting the proxy handle authentiction breaks the SIP protocol in bad ways and is generally not a good solution.
You may want to send another response to asterisk when you get the 407 so Asterisk retries and use the retry as a trigger for the second INVITE and add auth to that.
While breaking the cseq incrementation for authentication (mentioned in the readme of uac), the Asterisk seems to do ok here, because the ACK is coming from asterisk, but it is not accepted by the provider.
You are missing the fact that the ACK sent by Asterisk is already sent by the proxy. The INVITE w/AUth have a different cseq than the ACK.
Kamailio is doing serial forking in this case, so the first ack is for the first branch that gets 407. This should be as usual for serial/parallel forking.

Then, Kamailio is not increasing the cseq here -- that's the limitation with uac auth module, because the authenticator should normally reject it. But if it is authentication against another kamailio, should just work.



The provider (having a plivo platform, based on the responses) is running kamailio 4.1.2 in front (looking at 100 trying).

Authentication from kamailio to another kamailio using uac module should work fine, as kamailio doesn't act as end user UAC and doesn't care much of cseq.
Won't the second ACK on the same transaction just be ignored, while it waits for an ACK on the new transaction?
It is the same transaction in this case, just two branches from kamailio downstream, which is serial forking case, as mentioned above.


Cheers,
Daniel

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Next Kamailio Advanced Trainings 2014 - http://www.asipto.com
Sep 22-25, Berlin, Germany ::: Oct 15-17, San Francisco, USA

_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users



-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Next Kamailio Advanced Trainings 2014 - http://www.asipto.com
Sep 22-25, Berlin, Germany ::: Oct 15-17, San Francisco, USA

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Next Kamailio Advanced Trainings 2014 - http://www.asipto.com
Sep 22-25, Berlin, Germany ::: Oct 15-17, San Francisco, USA

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Next Kamailio Advanced Trainings 2014 - http://www.asipto.com
Sep 22-25, Berlin, Germany ::: Oct 15-17, San Francisco, USA

_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users