Re: [SR-Users] ACK to 200 OK without to tag
On Tue, Jun 05, 2018 at 12:29:49AM +0200, Kjeld Flarup wrote: > That clearly sound like a bug in the Grandstream. > > But lets say that we simply need to make this work. > > Is it possible to save the TO field from the 200 OK and reapply it to the > ACK before processing? This really isn't a reasonable approach. :-) -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] ACK to 200 OK without to tag
That clearly sound like a bug in the Grandstream.
But lets say that we simply need to make this work.
Is it possible to save the TO field from the 200 OK and reapply it to
the ACK before processing?
Med Liberalistiske Hilsner --
Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk
On 06/03/2018 11:06 PM, Alex Balashov wrote:
The end-to-end ACK for a 2xx reply to an INVITE is an in-dialog request
and must have a To-tag.
On Sun, Jun 03, 2018 at 11:04:47PM +0200, Kjeld Flarup wrote:
We have a SIP doorstation Grandstream GDS3710. When I connect it via
kamailio, it does not setup call correct.
Kamailio sends a 200 OK with this to field:
t:
;tag=e33a13d3-c18c-4df1-b68f-446e42957de6
Grandstream answers with:
To:
As the code follows this example:
https://kamailio.org/docs/modules/4.3.x/modules/dispatcher.html#dispatcher.ex.config,
it seems obvious that this will fail, as there is not
route[WITHINDLG] {
if (has_totag()) {
There simply is not to tag. Is this a bug in the grandstream?
If so how could that go unnoticed, or is it me who misses something?
I have attached the full sip text for the 200OK and the ACK
--
Med Liberalistiske Hilsner --
Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk
43847 12:49:34.444277192.168.1.150 192.168.1.155 SIP/SDP
320Status: 200 OK |
Frame 43847: 320 bytes on wire (2560 bits), 320 bytes captured (2560 bits)
Encapsulation type: Linux cooked-mode capture (25)
Arrival Time: Jun 3, 2018 14:49:34.444277000 CEST
[Time shift for this packet: 0.0 seconds]
Epoch Time: 1528030174.444277000 seconds
[Time delta from previous captured frame: 0.26000 seconds]
[Time delta from previous displayed frame: 0.26000 seconds]
[Time since reference or first frame: 21839.020163000 seconds]
Frame Number: 43847
Frame Length: 320 bytes (2560 bits)
Capture Length: 320 bytes (2560 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: sll:ethertype:ip:udp:sip:sdp]
[Coloring Rule Name: UDP]
[Coloring Rule String: udp]
Linux cooked capture
Packet type: Sent by us (4)
Link-layer address type: 1
Link-layer address length: 6
Source: Raspberr_fb:99:9f (b8:27:eb:fb:99:9f)
Unused: fffe
Protocol: IPv4 (0x0800)
Internet Protocol Version 4, Src: 192.168.1.150, Dst: 192.168.1.155
0100 = Version: 4
0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x10 (DSCP: Unknown, ECN: Not-ECT)
0001 00.. = Differentiated Services Codepoint: Unknown (4)
..00 = Explicit Congestion Notification: Not ECN-Capable
Transport (0)
Total Length: 304
Identification: 0x3c2f (15407)
Flags: 0x00b9
0... = Reserved bit: Not set
.0.. = Don't fragment: Not set
..0. = More fragments: Not set
...0 1011 1001 = Fragment offset: 185
Time to live: 64
Protocol: UDP (17)
Header checksum: 0xb843 [validation disabled]
[Header checksum status: Unverified]
Source: 192.168.1.150
Destination: 192.168.1.155
[2 IPv4 Fragments (1764 bytes): #43845(1480), #43847(284)]
[Frame: 43845, payload: 0-1479 (1480 bytes)]
[Frame: 43847, payload: 1480-1763 (284 bytes)]
[Fragment count: 2]
[Reassembled IPv4 length: 1764]
[Reassembled IPv4 data:
13cd13c406e440da5349502f322e3020323030204f4b0d0a...]
User Datagram Protocol, Src Port: 5069, Dst Port: 5060
Source Port: 5069
Destination Port: 5060
Length: 1764
Checksum: 0x40da [unverified]
[Checksum Status: Unverified]
[Stream index: 3]
Session Initiation Protocol (200)
Status-Line: SIP/2.0 200 OK
Status-Code: 200
[Resent Packet: True]
[Suspected resend of frame: 43826]
[Request Frame: 43831]
[Response Time (ms): 498]
Message Header
v: SIP/2.0/UDP
192.168.1.155:5060;rport=5060;received=192.168.1.155;branch=z9hG4bK1571336256
Transport: UDP
Sent-by Address: 192.168.1.155
Sent-by port: 5060
RPort: 5060
Received: 192.168.1.155
Branch: z9hG4bK1571336256
Record-Route:
Record-Route URI:
sip:5.103.133.210:5070;transport=tcp;lr;r2=on;ftag=851466465;vst=CwUAARgIAAAUBAoCATg1MDt0cmFuc3BvcnQ9VENQO29i;nat=yes
Record-Route Host Part: 5.103.133.210
Record-Route Host Port: 5070
Re: [SR-Users] ACK to 200 OK without to tag
The end-to-end ACK for a 2xx reply to an INVITE is an in-dialog request
and must have a To-tag.
On Sun, Jun 03, 2018 at 11:04:47PM +0200, Kjeld Flarup wrote:
> We have a SIP doorstation Grandstream GDS3710. When I connect it via
> kamailio, it does not setup call correct.
>
> Kamailio sends a 200 OK with this to field:
> t:
> ;tag=e33a13d3-c18c-4df1-b68f-446e42957de6
>
> Grandstream answers with:
> To:
>
> As the code follows this example:
> https://kamailio.org/docs/modules/4.3.x/modules/dispatcher.html#dispatcher.ex.config,
> it seems obvious that this will fail, as there is not
>
> route[WITHINDLG] {
> if (has_totag()) {
>
> There simply is not to tag. Is this a bug in the grandstream?
>
> If so how could that go unnoticed, or is it me who misses something?
>
> I have attached the full sip text for the 200OK and the ACK
>
> --
> Med Liberalistiske Hilsner --
>Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
>Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
>Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk
>
> 43847 12:49:34.444277192.168.1.150 192.168.1.155
> SIP/SDP 320Status: 200 OK |
>
> Frame 43847: 320 bytes on wire (2560 bits), 320 bytes captured (2560 bits)
> Encapsulation type: Linux cooked-mode capture (25)
> Arrival Time: Jun 3, 2018 14:49:34.444277000 CEST
> [Time shift for this packet: 0.0 seconds]
> Epoch Time: 1528030174.444277000 seconds
> [Time delta from previous captured frame: 0.26000 seconds]
> [Time delta from previous displayed frame: 0.26000 seconds]
> [Time since reference or first frame: 21839.020163000 seconds]
> Frame Number: 43847
> Frame Length: 320 bytes (2560 bits)
> Capture Length: 320 bytes (2560 bits)
> [Frame is marked: False]
> [Frame is ignored: False]
> [Protocols in frame: sll:ethertype:ip:udp:sip:sdp]
> [Coloring Rule Name: UDP]
> [Coloring Rule String: udp]
> Linux cooked capture
> Packet type: Sent by us (4)
> Link-layer address type: 1
> Link-layer address length: 6
> Source: Raspberr_fb:99:9f (b8:27:eb:fb:99:9f)
> Unused: fffe
> Protocol: IPv4 (0x0800)
> Internet Protocol Version 4, Src: 192.168.1.150, Dst: 192.168.1.155
> 0100 = Version: 4
> 0101 = Header Length: 20 bytes (5)
> Differentiated Services Field: 0x10 (DSCP: Unknown, ECN: Not-ECT)
> 0001 00.. = Differentiated Services Codepoint: Unknown (4)
> ..00 = Explicit Congestion Notification: Not ECN-Capable
> Transport (0)
> Total Length: 304
> Identification: 0x3c2f (15407)
> Flags: 0x00b9
> 0... = Reserved bit: Not set
> .0.. = Don't fragment: Not set
> ..0. = More fragments: Not set
> ...0 1011 1001 = Fragment offset: 185
> Time to live: 64
> Protocol: UDP (17)
> Header checksum: 0xb843 [validation disabled]
> [Header checksum status: Unverified]
> Source: 192.168.1.150
> Destination: 192.168.1.155
> [2 IPv4 Fragments (1764 bytes): #43845(1480), #43847(284)]
> [Frame: 43845, payload: 0-1479 (1480 bytes)]
> [Frame: 43847, payload: 1480-1763 (284 bytes)]
> [Fragment count: 2]
> [Reassembled IPv4 length: 1764]
> [Reassembled IPv4 data:
> 13cd13c406e440da5349502f322e3020323030204f4b0d0a...]
> User Datagram Protocol, Src Port: 5069, Dst Port: 5060
> Source Port: 5069
> Destination Port: 5060
> Length: 1764
> Checksum: 0x40da [unverified]
> [Checksum Status: Unverified]
> [Stream index: 3]
> Session Initiation Protocol (200)
> Status-Line: SIP/2.0 200 OK
> Status-Code: 200
> [Resent Packet: True]
> [Suspected resend of frame: 43826]
> [Request Frame: 43831]
> [Response Time (ms): 498]
> Message Header
> v: SIP/2.0/UDP
> 192.168.1.155:5060;rport=5060;received=192.168.1.155;branch=z9hG4bK1571336256
> Transport: UDP
> Sent-by Address: 192.168.1.155
> Sent-by port: 5060
> RPort: 5060
> Received: 192.168.1.155
> Branch: z9hG4bK1571336256
> Record-Route:
>
> Record-Route URI:
> sip:5.103.133.210:5070;transport=tcp;lr;r2=on;ftag=851466465;vst=CwUAARgIAAAUBAoCATg1MDt0cmFuc3BvcnQ9VENQO29i;nat=yes
> Record-Route Host Part: 5.103.133.210
> Record-Route Host Port: 5070
> Record-Route URI parameter: transport=tcp
> Record-Route URI parameter: lr
> Record-Route URI parameter: r2=on
> Record-Route URI parameter: ftag=851466465
> Record-Route URI parameter:
> vst=CwUAARgIAAAUBAoCATg1MDt0cmFuc3BvcnQ9VENQO29i
>
[SR-Users] ACK to 200 OK without to tag
We have a SIP doorstation Grandstream GDS3710. When I connect it via
kamailio, it does not setup call correct.
Kamailio sends a 200 OK with this to field:
t:
;tag=e33a13d3-c18c-4df1-b68f-446e42957de6
Grandstream answers with:
To:
As the code follows this example:
https://kamailio.org/docs/modules/4.3.x/modules/dispatcher.html#dispatcher.ex.config,
it seems obvious that this will fail, as there is not
route[WITHINDLG] {
if (has_totag()) {
There simply is not to tag. Is this a bug in the grandstream?
If so how could that go unnoticed, or is it me who misses something?
I have attached the full sip text for the 200OK and the ACK
--
Med Liberalistiske Hilsner --
Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk
43847 12:49:34.444277192.168.1.150 192.168.1.155 SIP/SDP
320Status: 200 OK |
Frame 43847: 320 bytes on wire (2560 bits), 320 bytes captured (2560 bits)
Encapsulation type: Linux cooked-mode capture (25)
Arrival Time: Jun 3, 2018 14:49:34.444277000 CEST
[Time shift for this packet: 0.0 seconds]
Epoch Time: 1528030174.444277000 seconds
[Time delta from previous captured frame: 0.26000 seconds]
[Time delta from previous displayed frame: 0.26000 seconds]
[Time since reference or first frame: 21839.020163000 seconds]
Frame Number: 43847
Frame Length: 320 bytes (2560 bits)
Capture Length: 320 bytes (2560 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: sll:ethertype:ip:udp:sip:sdp]
[Coloring Rule Name: UDP]
[Coloring Rule String: udp]
Linux cooked capture
Packet type: Sent by us (4)
Link-layer address type: 1
Link-layer address length: 6
Source: Raspberr_fb:99:9f (b8:27:eb:fb:99:9f)
Unused: fffe
Protocol: IPv4 (0x0800)
Internet Protocol Version 4, Src: 192.168.1.150, Dst: 192.168.1.155
0100 = Version: 4
0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x10 (DSCP: Unknown, ECN: Not-ECT)
0001 00.. = Differentiated Services Codepoint: Unknown (4)
..00 = Explicit Congestion Notification: Not ECN-Capable Transport
(0)
Total Length: 304
Identification: 0x3c2f (15407)
Flags: 0x00b9
0... = Reserved bit: Not set
.0.. = Don't fragment: Not set
..0. = More fragments: Not set
...0 1011 1001 = Fragment offset: 185
Time to live: 64
Protocol: UDP (17)
Header checksum: 0xb843 [validation disabled]
[Header checksum status: Unverified]
Source: 192.168.1.150
Destination: 192.168.1.155
[2 IPv4 Fragments (1764 bytes): #43845(1480), #43847(284)]
[Frame: 43845, payload: 0-1479 (1480 bytes)]
[Frame: 43847, payload: 1480-1763 (284 bytes)]
[Fragment count: 2]
[Reassembled IPv4 length: 1764]
[Reassembled IPv4 data:
13cd13c406e440da5349502f322e3020323030204f4b0d0a...]
User Datagram Protocol, Src Port: 5069, Dst Port: 5060
Source Port: 5069
Destination Port: 5060
Length: 1764
Checksum: 0x40da [unverified]
[Checksum Status: Unverified]
[Stream index: 3]
Session Initiation Protocol (200)
Status-Line: SIP/2.0 200 OK
Status-Code: 200
[Resent Packet: True]
[Suspected resend of frame: 43826]
[Request Frame: 43831]
[Response Time (ms): 498]
Message Header
v: SIP/2.0/UDP
192.168.1.155:5060;rport=5060;received=192.168.1.155;branch=z9hG4bK1571336256
Transport: UDP
Sent-by Address: 192.168.1.155
Sent-by port: 5060
RPort: 5060
Received: 192.168.1.155
Branch: z9hG4bK1571336256
Record-Route:
Record-Route URI:
sip:5.103.133.210:5070;transport=tcp;lr;r2=on;ftag=851466465;vst=CwUAARgIAAAUBAoCATg1MDt0cmFuc3BvcnQ9VENQO29i;nat=yes
Record-Route Host Part: 5.103.133.210
Record-Route Host Port: 5070
Record-Route URI parameter: transport=tcp
Record-Route URI parameter: lr
Record-Route URI parameter: r2=on
Record-Route URI parameter: ftag=851466465
Record-Route URI parameter:
vst=CwUAARgIAAAUBAoCATg1MDt0cmFuc3BvcnQ9VENQO29i
Record-Route URI parameter: nat=yes
Record-Route:
Record-Route URI:
sip:127.0.0.1:5070;lr;r2=on;ftag=851466465;vst=CwUAARgIAAAUBAoCATg1MDt0cmFuc3BvcnQ9VENQO29i;nat=yes
Record-Route Host Part: 127.0.0.1
Record-Route Host Port: 5070
Record-Route URI parameter: lr
Record-Route URI parameter:
