PDA

View Full Version : Call-Info header removal



ssteiner
10-13-2007, 11:38 PM
according to section 20 of the RFC 3162, a proxy may not remove a Call-Info header from any request. However, that's just what the Quadro does when I try to initiate a directed page from a Linksys phone (they have a phone specific prefix to page a specific extension).

Here's what happens if I try to page extension 52 from extension 56.


15:28:54 Receive SIP message # (14/10/2007 13:28:54:588 GMT) # UDP #
1034 bytes # from: 192.168.1.100:5065 # to: 192.168.1.10:5060



***************************** SIP message buffer start *****************************

INVITE sip:52@192.168.1.10 SIP/2.0

Via: SIP/2.0/UDP 192.168.1.100:5065;branch=z9hG4bK-3d379873

From: "Stephan" <sip:56@192.168.1.10>;tag=2931f4831b06df3o5

To: <sip:52@192.168.1.10>

Call-Info: <sip:192.168.1.10>;answer-after=0

Call-ID: eafbaf74-236c07b3@192.168.1.100

CSeq: 101 INVITE

Max-Forwards: 70

Contact: "Stephan" <sip:56@192.168.1.100:5065>;+sip.instance="<0000000 0-0000-0000-0000-000E08DD6BFA>"

Expires: 240

User-Agent: Linksys/SPA962-5.1.15(aSC)

Content-Length: 397

Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER, SUBSCRIBE

Allow-Events: dialog

Supported: replaces

Content-Type: application/sdp



v=0

o=- 384539 384539 IN IP4 192.168.1.100

s=-

c=IN IP4 192.168.1.100

t=0 0

m=audio 16420 RTP/AVP 8 0 2 4 18 96 97 98 101

a=rtpmap:8 PCMA/8000

a=rtpmap:0 PCMU/8000

a=rtpmap:2 G726-32/8000

a=rtpmap:4 G723/8000

a=rtpmap:18 G729a/8000

a=rtpmap:96 G726-40/8000

a=rtpmap:97 G726-24/8000

a=rtpmap:98 G726-16/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

a=ptime:30

a=sendrecv

***************************** SIP message buffer end ******************************



15:28:54 Try to send SIP message # (14/10/2007 13:28:54:593 GMT) #
UDP # 250 bytes # from: 192.168.1.10:5060 # to: 192.168.1.100:5065



***************************** SIP message buffer start *****************************

SIP/2.0 100 Trying

Via: SIP/2.0/UDP 192.168.1.100:5065;branch=z9hG4bK-3d379873

To: <sip:52@192.168.1.10>

From: "Stephan" <sip:56@192.168.1.10>;tag=2931f4831b06df3o5

CSeq: 101 INVITE

Call-ID: eafbaf74-236c07b3@192.168.1.100

Content-Length: 0



***************************** SIP message buffer end ******************************




------------------- Application Log Started At 2007/10/14 15:28:54 -------------------

15:28:54 TLayer::MsgToTU # Msg type: 51 # TID: 7128 # DID: 0

15:28:54 UACore::TLReqMsgProc # Got INVITE SIP request

15:28:54 Try to send SIP message # (14/10/2007 13:28:54:609 GMT) #
UDP # 432 bytes # from: 192.168.1.10:5060 # to: 192.168.1.100:5065



***************************** SIP message buffer start *****************************

SIP/2.0 401 Unauthorized

Via: SIP/2.0/UDP 192.168.1.100:5065;branch=z9hG4bK-3d379873

To: <sip:52@192.168.1.10>

From: "Stephan" <sip:56@192.168.1.10>;tag=2931f4831b06df3o5

CSeq: 101 INVITE

Call-ID: eafbaf74-236c07b3@192.168.1.100

Server: Epygi Quadro SIP User Agent/v4.1.33 (QUADRO-2X)

WWW-Authenticate: Digest realm="quadro.epygi-config.com",nonce="752dc605b4398a9ebe02b 0e8e8fa65ce",opaque="1192368534"

Content-Length: 0



***************************** SIP message buffer end ******************************



15:28:54 Receive SIP message # (14/10/2007 13:28:54:624 GMT) # UDP
# 443 bytes # from: 192.168.1.100:5065 # to: 192.168.1.10:5060



***************************** SIP message buffer start *****************************

ACK sip:52@192.168.1.10 SIP/2.0

Via: SIP/2.0/UDP 192.168.1.100:5065;branch=z9hG4bK-3d379873

From: "Stephan" <sip:56@192.168.1.10>;tag=2931f4831b06df3o5

To: <sip:52@192.168.1.10>

Call-ID: eafbaf74-236c07b3@192.168.1.100

CSeq: 101 ACK

Max-Forwards: 70

Contact: "Stephan" <sip:56@192.168.1.100:5065>;+sip.instance="<0000000 0-0000-0000-0000-000E08DD6BFA>"

User-Agent: Linksys/SPA962-5.1.15(aSC)

Content-Length: 0

Allow-Events: dialog



***************************** SIP message buffer end ******************************



15:28:54 Receive SIP message # (14/10/2007 13:28:54:635 GMT) # UDP
# 1248 bytes # from: 192.168.1.100:5065 # to: 192.168.1.10:5060



***************************** SIP message buffer start *****************************

INVITE sip:52@192.168.1.10 SIP/2.0

Via: SIP/2.0/UDP 192.168.1.100:5065;branch=z9hG4bK-d6ad5c83

From: "Stephan" <sip:56@192.168.1.10>;tag=2931f4831b06df3o5

To: <sip:52@192.168.1.10>

Call-Info: <sip:192.168.1.10>;answer-after=0

Call-ID: eafbaf74-236c07b3@192.168.1.100

CSeq: 102 INVITE

Max-Forwards: 70

Authorization: Digest
username="56",realm="quadro.epygi-config.com",nonce= "752dc605b4398a9ebe02b0e8e8fa65ce",uri="sip:52@192.168.1.10" ,algorithm=MD5,response="29f03d26c97df4441714f0178442d5df",o paque="1192368534"

Contact: "Stephan" <sip:56@192.168.1.100:5065>;+sip.instance="<0000000 0-0000-0000-0000-000E08DD6BFA>"

Expires: 240

User-Agent: Linksys/SPA962-5.1.15(aSC)

Content-Length: 397

Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER, SUBSCRIBE

Allow-Events: dialog

Supported: replaces

Content-Type: application/sdp



v=0

o=- 384539 384539 IN IP4 192.168.1.100

s=-

c=IN IP4 192.168.1.100

t=0 0

m=audio 16420 RTP/AVP 8 0 2 4 18 96 97 98 101

a=rtpmap:8 PCMA/8000

a=rtpmap:0 PCMU/8000

a=rtpmap:2 G726-32/8000

a=rtpmap:4 G723/8000

a=rtpmap:18 G729a/8000

a=rtpmap:96 G726-40/8000

a=rtpmap:97 G726-24/8000

a=rtpmap:98 G726-16/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

a=ptime:30

a=sendrecv

***************************** SIP message buffer end ******************************



15:28:54 Try to send SIP message # (14/10/2007 13:28:54:654 GMT) #
UDP # 250 bytes # from: 192.168.1.10:5060 # to: 192.168.1.100:5065



***************************** SIP message buffer start *****************************

SIP/2.0 100 Trying

Via: SIP/2.0/UDP 192.168.1.100:5065;branch=z9hG4bK-d6ad5c83

To: <sip:52@192.168.1.10>

From: "Stephan" <sip:56@192.168.1.10>;tag=2931f4831b06df3o5

CSeq: 102 INVITE

Call-ID: eafbaf74-236c07b3@192.168.1.100

Content-Length: 0



***************************** SIP message buffer end ******************************



15:28:54 TLayer::MsgToTU # Msg type: 51 # TID: 7129 # DID: 0

15:28:54 UACore::TLReqMsgProc # Got INVITE SIP request

15:28:54 SipSessDlg: # Call ID Info # SID: 5121183858310124256 # 15:28:54 SipID: eafbaf74-236c07b3@192.168.1.100

15:28:54 SipSessDlg::ChangeSessTimerFlag # user 56 registered on UA # SessionTimer = 0

15:28:54 SipSessDlg::ChangeSessTimerFlag # user 56 # SessionTimer = 0

15:28:54 SipSessDlg::IncInviteProc # Got INVITE message # OID: 7132 # SID: 5121183858310124256

15:28:54 TargetQualifier::QualifyTargets # Try to qualify targets for dest 192.168.1.100 # OID: 7132

15:28:54 TargetQualifier::NatHandling # Don't need nat settings - direct reach # OID: 7132

15:28:54 UA --> CM # MakeCall # from: 56@192.168.1.10:, to: 52,
child: (empty), media exist, GUID: (empty) # ContactInfo: 192.168.1.100
# SID: 5121183858310124256

15:28:55 CallsAgent::OnMakeCall # MakeCall from CM # SID: 5094685911557058

15:28:55 CallsAgent::OnMakeCall # Empty GUID from CM # SID: 5094685911557058

15:28:55 SipSessDlg: # Call ID Info # SID: 5094685911557058 #
15:28:55 SipID:
a5b8dcbf-bc75-4fc2-8f58-4f5fe5962758@quadro.epygi-co nfig.com

15:28:55 SipSessDlg::ChangeSessTimerFlag # user 52 registered on UA # SessionTimer = 0

15:28:55 SipSessDlg::ChangeSessTimerFlag # user 52 # SessionTimer = 0

15:28:55 CM --> UA # MakeCall # from: 56, to:
52@192.168.1.104:1025, media exist # replaceSID: 0 # privacy: 0 #
AlertInfo: not exist # AddInfo: [SP#192.168.1.10:5060][BND#52] #OID:
7138 # SID: 5094685911557058

15:28:55 SipDlg::DetermineInitTarget # Call to primary server # OID: 7138

15:28:55 TargetQualifier::QualifyTargets # Try to qualify targets for dest 192.168.1.104 # OID: 7138

15:28:55 TargetQualifier::NatHandling # Don't need nat settings - direct reach # OID: 7138

15:28:55 SipSessDlg::SelfMediaHandling # State: local offer, Peer
Public Key: empty, SRTP flag: false, Sesssion Key: empty # OID: 7138 #
SID: 5094685911557058

15:28:55 Try to send SIP message # (14/10/2007 13:28:55:068 GMT) #
UDP # 896 bytes # from: 192.168.1.10:5060 # to: 192.168.1.104:1025



***************************** SIP message buffer start *****************************

INVITE sip:52@192.168.1.104:1025 SIP/2.0

Via: SIP/2.0/UDP 192.168.1.10:5060;rport;branch=z9hG4bKEPSVBUSddce5 f6e-a602-4 f07-bd63-eb0fde95fc4b

To: <sip:52@192.168.1.10:5060>

From: "Stephan SPA962" <sip:56@192.168.1.10>;tag=1192355697b378de45-fb89-4bf6 -9dc7-c7f84e1fea7c

CSeq: 213 INVITE

Call-ID: a5b8dcbf-bc75-4fc2-8f58-4f5fe5962758@quadro.epygi-config.com

Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, UPDATE

Contact: "Stephan SPA962" <sip:56@192.168.1.10:5060>

Content-Type: application/sdp

Supported: replaces, norefersub

User-Agent: Epygi Quadro SIP User Agent/v4.1.33 (QUADRO-2X)

Max-Forwards: 70

Content-Length: 225



v=0

o=56 354 89 IN IP4 192.168.1.10

s=-

c=IN IP4 192.168.1.10

t=0 0

m=audio 6046 RTP/AVP 0 8 18 101

a=rtpmap:0 PCMU/8000

a=rtpmap:8 PCMA/8000

a=rtpmap:18 G729/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

***************************** SIP message buffer end ******************************


As you can see, the originating phone tries to page by use of

Call-Info: <sip:192.168.1.10>;answer-after=0

After authentication of the request, the quadro forwards the INVITE to the destination after having removed that header field. Thus, the page returns in a regular call.

The same happens when I initiate a directed page from a grandstream phone:


15:35:32 Receive SIP message # (14/10/2007 13:35:32:060 GMT) # UDP #
1023 bytes # from: 192.168.1.122:5060 # to: 192.168.1.10:5060



***************************** SIP message buffer start *****************************

INVITE sip:52@192.168.1.10;user=phone SIP/2.0

Via: SIP/2.0/UDP 192.168.1.122:5060;branch=z9hG4bK33817644ce07d017

From: "Stephan GXP2020" <sip:54@192.168.1.10;user=phone>;tag=5e7391b6b1a6cfa6


To: <sip:52@192.168.1.10;user=phone>

Contact: <sip:54@192.168.1.122:5060;transport=udp;user=phone>

Supported: replaces, timer, path

Call-ID: 0785a080d29041d5@192.168.1.122

Call-Info: answer-after=0

CSeq: 22063 INVITE

User-Agent: Grandstream GXP2020 1.1.4.22

Max-Forwards: 70

Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SU BSCRIBE,UP DATE,PRACK,MESSAGE

Content-Type: application/sdp

Content-Length: 405



v=0

o=54 8000 8000 IN IP4 192.168.1.122

s=SIP Call

c=IN IP4 192.168.1.122

t=0 0

m=audio 5004 RTP/AVP 8 0 4 18 2 97 9 3 101

a=sendrecv

a=rtpmap:8 PCMA/8000

a=rtpmap:0 PCMU/8000

a=rtpmap:4 G723/8000

a=rtpmap:18 G729/8000

a=rtpmap:2 G726-32/8000

a=rtpmap:97 iLBC/8000

a=fmtp:97 mode=20

a=rtpmap:9 G722/16000

a=rtpmap:3 GSM/8000

a=ptime:20

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-11

***************************** SIP message buffer end ******************************



15:35:32 Try to send SIP message # (14/10/2007 13:35:32:064 GMT) #
UDP # 287 bytes # from: 192.168.1.10:5060 # to: 192.168.1.122:5060



***************************** SIP message buffer start *****************************

SIP/2.0 100 Trying

Via: SIP/2.0/UDP 192.168.1.122:5060;branch=z9hG4bK33817644ce07d017

To: <sip:52@192.168.1.10;user=phone>

From: "Stephan GXP2020" <sip:54@192.168.1.10;user=phone>;tag=5e7391b6b1a6cfa6


CSeq: 22063 INVITE

Call-ID: 0785a080d29041d5@192.168.1.122

Content-Length: 0



***************************** SIP message buffer end ******************************



15:35:32 TLayer::MsgToTU # Msg type: 51 # TID: 7346 # DID: 0

15:35:32 UACore::TLReqMsgProc # Got INVITE SIP request

15:35:32 Try to send SIP message # (14/10/2007 13:35:32:089 GMT) #
UDP # 469 bytes # from: 192.168.1.10:5060 # to: 192.168.1.122:5060



***************************** SIP message buffer start *****************************

SIP/2.0 401 Unauthorized

Via: SIP/2.0/UDP 192.168.1.122:5060;branch=z9hG4bK33817644ce07d017

To: <sip:52@192.168.1.10;user=phone>

From: "Stephan GXP2020" <sip:54@192.168.1.10;user=phone>;tag=5e7391b6b1a6cfa6


CSeq: 22063 INVITE

Call-ID: 0785a080d29041d5@192.168.1.122

Server: Epygi Quadro SIP User Agent/v4.1.33 (QUADRO-2X)

WWW-Authenticate: Digest realm="quadro.epygi-config.com",nonce="5de995c77e703bdefa036 64b949d5568",opaque="1192368932"

Content-Length: 0



***************************** SIP message buffer end ******************************



15:35:32 Receive SIP message # (14/10/2007 13:35:32:143 GMT) # UDP
# 535 bytes # from: 192.168.1.122:5060 # to: 192.168.1.10:5060



***************************** SIP message buffer start *****************************

ACK sip:52@192.168.1.10;user=phone SIP/2.0

Via: SIP/2.0/UDP 192.168.1.122:5060;branch=z9hG4bK33817644ce07d017

From: "Stephan GXP2020" <sip:54@192.168.1.10;user=phone>;tag=5e7391b6b1a6cfa6


To: <sip:52@192.168.1.10;user=phone>

Contact: <sip:54@192.168.1.122:5060;transport=udp;user=phone>

Supported: path

Call-ID: 0785a080d29041d5@192.168.1.122

CSeq: 22063 ACK

User-Agent: Grandstream GXP2020 1.1.4.22

Max-Forwards: 70

Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SU BSCRIBE,UP DATE,PRACK,MESSAGE

Content-Length: 0



***************************** SIP message buffer end ******************************



15:35:32 Receive SIP message # (14/10/2007 13:35:32:176 GMT) # UDP
# 1254 bytes # from: 192.168.1.122:5060 # to: 192.168.1.10:5060



***************************** SIP message buffer start *****************************

INVITE sip:52@192.168.1.10;user=phone SIP/2.0

Via: SIP/2.0/UDP 192.168.1.122:5060;branch=z9hG4bK8d80017cdfd5179f

From: "Stephan GXP2020" <sip:54@192.168.1.10;user=phone>;tag=5e7391b6b1a6cfa6


To: <sip:52@192.168.1.10;user=phone>

Contact: <sip:54@192.168.1.122:5060;transport=udp;user=phone>

Supported: replaces, timer, path

Authorization: Digest username="54",
realm="quadro.epygi-config.com", algorithm=MD5,
uri="sip:52@192.168.1.10;user=phone", opaque="1192368932",
nonce="5de995c77e703bdefa03664b949d556 8",
response="73c4ce938c7231667bb74c0dac7576cc"

Call-ID: 0785a080d29041d5@192.168.1.122

Call-Info: answer-after=0

CSeq: 22064 INVITE

User-Agent: Grandstream GXP2020 1.1.4.22

Max-Forwards: 70

Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SU BSCRIBE,UP DATE,PRACK,MESSAGE

Content-Type: application/sdp

Content-Length: 405



v=0

o=54 8000 8001 IN IP4 192.168.1.122

s=SIP Call

c=IN IP4 192.168.1.122

t=0 0

m=audio 5004 RTP/AVP 8 0 4 18 2 97 9 3 101

a=sendrecv

a=rtpmap:8 PCMA/8000

a=rtpmap:0 PCMU/8000

a=rtpmap:4 G723/8000

a=rtpmap:18 G729/8000

a=rtpmap:2 G726-32/8000

a=rtpmap:97 iLBC/8000

a=fmtp:97 mode=20

a=rtpmap:9 G722/16000

a=rtpmap:3 GSM/8000

a=ptime:20

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-11

***************************** SIP message buffer end ******************************



15:35:32 Try to send SIP message # (14/10/2007 13:35:32:181 GMT) #
UDP # 287 bytes # from: 192.168.1.10:5060 # to: 192.168.1.122:5060



***************************** SIP message buffer start *****************************

SIP/2.0 100 Trying

Via: SIP/2.0/UDP 192.168.1.122:5060;branch=z9hG4bK8d80017cdfd5179f

To: <sip:52@192.168.1.10;user=phone>

From: "Stephan GXP2020" <sip:54@192.168.1.10;user=phone>;tag=5e7391b6b1a6cfa6


CSeq: 22064 INVITE

Call-ID: 0785a080d29041d5@192.168.1.122

Content-Length: 0



***************************** SIP message buffer end ******************************



15:35:32 TLayer::MsgToTU # Msg type: 51 # TID: 7347 # DID: 0

15:35:32 UACore::TLReqMsgProc # Got INVITE SIP request

15:35:32 SipSessDlg: # Call ID Info # SID: 5121185567706633984 # 15:35:32 SipID: 0785a080d29041d5@192.168.1.122

15:35:32 SipSessDlg::ChangeSessTimerFlag # user 54 registered on UA # SessionTimer = 0

15:35:32 SipSessDlg::ChangeSessTimerFlag # user 54 # SessionTimer = 0

15:35:32 SipSessDlg::IncInviteProc # Got INVITE message # OID: 7348 # SID: 5121185567706633984

15:35:32 TargetQualifier::QualifyTargets # Try to qualify targets for dest 192.168.1.122 # OID: 7348

15:35:32 TargetQualifier::NatHandling # Don't need nat settings - direct reach # OID: 7348

15:35:32 UA --> CM # MakeCall # from: 54@192.168.1.10:, to: 52,
child: (empty), media exist, GUID: (empty) # ContactInfo: 192.168.1.122
# SID: 5121185567706633984

15:35:32 CallsAgent::OnMakeCall # MakeCall from CM # SID: 5096391013967042

15:35:32 CallsAgent::OnMakeCall # Empty GUID from CM # SID: 5096391013967042

15:35:32 SipSessDlg: # Call ID Info # SID: 5096391013967042 #
15:35:32 SipID:
8eb9cf49-57a7-4f3d-919d-9c9f9f664a07@quadro.epygi-co nfig.com

15:35:32 SipSessDlg::ChangeSessTimerFlag # user 52 registered on UA # SessionTimer = 0

15:35:32 SipSessDlg::ChangeSessTimerFlag # user 52 # SessionTimer = 0

15:35:32 CM --> UA # MakeCall # from: 54, to:
52@192.168.1.104:1025, media exist # replaceSID: 0 # privacy: 0 #
AlertInfo: not exist # AddInfo: [SP#192.168.1.10:5060][BND#52] #OID:
7351 # SID: 5096391013967042

15:35:32 SipDlg::DetermineInitTarget # Call to primary server # OID: 7351

15:35:32 TargetQualifier::QualifyTargets # Try to qualify targets for dest 192.168.1.104 # OID: 7351

15:35:32 TargetQualifier::NatHandling # Don't need nat settings - direct reach # OID: 7351

15:35:32 SipSessDlg::SelfMediaHandling # State: local offer, Peer
Public Key: empty, SRTP flag: false, Sesssion Key: empty # OID: 7351 #
SID: 5096391013967042

15:35:32 Try to send SIP message # (14/10/2007 13:35:32:505 GMT) #
UDP # 906 bytes # from: 192.168.1.10:5060 # to: 192.168.1.104:1025



***************************** SIP message buffer start *****************************

INVITE sip:52@192.168.1.104:1025 SIP/2.0

Via: SIP/2.0/UDP 192.168.1.10:5060;rport;branch=z9hG4bKEPSVBUS616ba a10-6b48-4 a85-92c1-7f4b0cac6c34

To: <sip:52@192.168.1.10:5060>

From: "Stephan Grandstream" <sip:54@192.168.1.10>;tag=1192355697e6c8e9cb-7d94-45eb -ad2b-04013f14e4b3

CSeq: 335 INVITE

Call-ID: 8eb9cf49-57a7-4f3d-919d-9c9f9f664a07@quadro.epygi-config.com

Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, UPDATE

Contact: "Stephan Grandstream" <sip:54@192.168.1.10:5060>

Content-Type: application/sdp

Supported: replaces, norefersub

User-Agent: Epygi Quadro SIP User Agent/v4.1.33 (QUADRO-2X)

Max-Forwards: 70

Content-Length: 225



v=0

o=54 34 321 IN IP4 192.168.1.10

s=-

c=IN IP4 192.168.1.10

t=0 0

m=audio 6050 RTP/AVP 0 8 18 101

a=rtpmap:0 PCMU/8000

a=rtpmap:8 PCMA/8000

a=rtpmap:18 G729/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

***************************** SIP message buffer end ******************************
It also uses the Call-Info header, which is once again removed by the Quadro.

I suspect this is also why I can't get a directed page betwen two Snom phones to work.

ssteiner
10-13-2007, 11:46 PM
Just checked how the Snom does it.. and they use the same header


15:43:49 Receive SIP message # (14/10/2007 13:43:49:417 GMT) # UDP #
1469 bytes # from: 192.168.1.104:1024 # to: 192.168.1.10:5060



***************************** SIP message buffer start *****************************

INVITE sip:53@192.168.1.10;user=phone;intercom=true SIP/2.0

Via: SIP/2.0/UDP 192.168.1.104:1025;branch=z9hG4bK-ra1pfdgk0n8z;rport

From: "Snom Epygi" <sip:52@192.168.1.10:5060>;tag=04a1jw3k7b

To: <sip:53@192.168.1.10;user=phone;intercom=true>

Call-ID: 3c26a45c29ca-3sh4xxp3rs5i

CSeq: 2 INVITE

Max-Forwards: 70

Contact: <sip:52@192.168.1.104:1025>;flow-id=1

P-Key-Flags: resolution="31x13", keys="4"

User-Agent: snom370/7.1.24

Accept: application/sdp

Alert-Info: <http://www.notused.com>;info=alert-autoanswer;delay=0

Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO

Allow-Events: talk, hold, refer, call-info

Supported: timer, 100rel, replaces, callerid

Session-Expires: 3600;refresher=uas

Min-SE: 90

Authorization: Digest
username="52",realm="quadro.epygi-config.com",nonce= "63db787bcbde579555ca1b6033f37caa",uri="sip:53@192.168.1.10; user=phone;intercom=true",response="592eedb659c63a22a46a6725 a1871f87",opaque="1192369429",algorithm=MD5

Content-Type: application/sdp

Content-Length: 419



v=0

o=root 861886447 861886447 IN IP4 192.168.1.104

s=call

c=IN IP4 192.168.1.104

t=0 0

m=audio 52384 RTP/AVP 0 8 9 2 3 18 4

a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:5mdI7//WuV3UovSV6SdqlH8r6C1+qu7rn181UdZz

a=rtpmap:0 pcmu/8000

a=rtpmap:8 pcma/8000

a=rtpmap:9 g722/8000

a=rtpmap:2 g726-32/8000

a=rtpmap:3 gsm/8000

a=rtpmap:18 g729/8000

a=rtpmap:4 g723/8000

a=ptime:20

a=encryption:optional

a=sendrecv

***************************** SIP message buffer end ******************************



15:43:49 Try to send SIP message # (14/10/2007 13:43:49:422 GMT) #
UDP # 283 bytes # from: 192.168.1.10:5060 # to: 192.168.1.104:1024



***************************** SIP message buffer start *****************************

SIP/2.0 100 Trying

Via: SIP/2.0/UDP 192.168.1.104:1025;rport=1024;branch=z9hG4bK-ra1pfdgk0n8z

To: <sip:53@192.168.1.10;user=phone;intercom=true>

From: "Snom Epygi" <sip:52@192.168.1.10:5060>;tag=04a1jw3k7b

CSeq: 2 INVITE

Call-ID: 3c26a45c29ca-3sh4xxp3rs5i

Content-Length: 0



***************************** SIP message buffer end ******************************



15:43:49 TLayer::MsgToTU # Msg type: 51 # TID: 7648 # DID: 0

15:43:49 UACore::TLReqMsgProc # Got INVITE SIP request

15:43:49 SipSessDlg: # Call ID Info # SID: 5121187702305621171 # 15:43:49 SipID: 3c26a45c29ca-3sh4xxp3rs5i

15:43:49 SipSessDlg::ChangeSessTimerFlag # user 52 registered on UA # SessionTimer = 0

15:43:49 SipSessDlg::ChangeSessTimerFlag # user 52 # SessionTimer = 0

15:43:49 SipSessDlg::IncInviteProc # Got INVITE message # OID: 7649 # SID: 5121187702305621171

15:43:49 TargetQualifier::QualifyTargets # Try to qualify targets for dest 192.168.1.104 # OID: 7649

15:43:49 TargetQualifier::NatHandling # Don't need nat settings - direct reach # OID: 7649

15:43:49 UA --> CM # MakeCall # from: 52@192.168.1.10:5060, to:
53, child: (empty), media exist, GUID: (empty) # ContactInfo:
192.168.1.104 # SID: 5121187702305621171

15:43:49 CallsAgent::OnMakeCall # MakeCall from CM # SID: 5098525612925036

15:43:49 CallsAgent::OnMakeCall # Empty GUID from CM # SID: 5098525612925036

15:43:49 SipSessDlg: # Call ID Info # SID: 5098525612925036 #
15:43:49 SipID:
dc669a33-70a8-4424-969f-79ba5492bdeb@quadro.epygi-co nfig.com

15:43:49 SipSessDlg::ChangeSessTimerFlag # user 53 registered on UA # SessionTimer = 1

15:43:49 SipSessDlg::ChangeSessTimerFlag # user 53 # SessionTimer = 1

15:43:49 CM --> UA # MakeCall # from: 52, to:
53@192.168.1.146:2048, media exist # replaceSID: 0 # privacy: 20000 #
AlertInfo: not exist # AddInfo: [SP#192.168.1.10:5060][BND#53] #OID:
7650 # SID: 5098525612925036

15:43:49 SipDlg::DetermineInitTarget # Call to primary server # OID: 7650

15:43:49 TargetQualifier::QualifyTargets # Try to qualify targets for dest 192.168.1.146 # OID: 7650

15:43:49 TargetQualifier::NatHandling # Don't need nat settings - direct reach # OID: 7650

15:43:49 SipSessDlg::SelfMediaHandling # State: local offer, Peer
Public Key: empty, SRTP flag: false, Sesssion Key: empty # OID: 7650 #
SID: 5098525612925036

15:43:49 Try to send SIP message # (14/10/2007 13:43:49:668 GMT) #
UDP # 878 bytes # from: 192.168.1.10:5060 # to: 192.168.1.146:2048



***************************** SIP message buffer start *****************************

INVITE sip:53@192.168.1.146:2048 SIP/2.0

Via: SIP/2.0/UDP 192.168.1.10:5060;rport;branch=z9hG4bKEPSVBUS76ee2 952-25ce-4 0b9-a53b-f13785a36eec

To: <sip:53@192.168.1.10:5060>

From: "Stephan Snom" <sip:52@192.168.1.10>;tag=11923556970aa3b73e-b6aa-44be -8dda-654892b94ff4

CSeq: 847 INVITE

Call-ID: dc669a33-70a8-4424-969f-79ba5492bdeb@quadro.epygi-config.com

Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, UPDATE

Contact: "Stephan Snom" <sip:52@192.168.1.10:5060>

Content-Type: application/sdp

Supported: replaces, norefersub, timer

User-Agent: Epygi Quadro SIP User Agent/v4.1.33 (QUADRO-2X)

Min-SE: 20

Session-Expires: 180

Max-Forwards: 70

Content-Length: 170



v=0

o=52 130 583 IN IP4 192.168.1.10

s=-

c=IN IP4 192.168.1.10

t=0 0

m=audio 6054 RTP/AVP 0 8 18

a=rtpmap:0 PCMU/8000

a=rtpmap:8 PCMA/8000

a=rtpmap:18 G729/8000

***************************** SIP message buffer end ******************************


Since it is removed, it's no surprise that directed intercom doesn't work on the snom either.

AramK
10-14-2007, 05:06 AM
This will be passed to the Epygi development, to see if there is a real contradiction between RFCs and Quadro behaviour. As to direct paging between Snom phones, we do not guarantee the correctfunctionalityof the phones' features, activated not by Quadro, but from the phones itself. That can bring to the phones' malfumctionand it is documented on all our documents.

ssteiner
10-14-2007, 06:21 AM
Of course what I said about Snom was incorrect.. they use Alert-Info. However, the situation is the same.. the RFC demands that this header be left alone (it's on page 161 of the RFC).


we do not guarantee the correctfunctionalityof the phones' features, activated not by QuadroThen again, you cannot guarantee it either by doing it from the proxy, unless you inspect requests, and match the phone type to a certain behavior.. your current paging doesn't work for Grandstream and Aastra phones because the Grandstreams don't like the uri in the Call-Info header, and because Aastra uses the Alert-Info header in a special way ;)

AramK
10-14-2007, 04:22 PM
We support paging for the Epygi Supported phones only and that are the following phones (just look at Paging Group Online Help):


SNOM 320 (SIP phone)


SNOM 360 (SIP phone)


Aastra 480i (SIP phone)


Aastra 9133i (SIP phone)


Aastra 9112i (SIP phone)


Aastra 480e (analog phone)


Also the phones of 5x seriesare included for the next release. No need to do some experiments, to find out the information that are already provided in our Help. As you can see there is no Grandsream phones in this list, as that phones aren't Supported phones, but just Tested phones. Some functionality may not work, or work in other way on that phones. And we have no problem with paging of Aastra phones. Maybe you have some beta-version on your Aastra, we don't know.I will suggest you again to read all the documentation regarding IP-Phones configuration and usage from our "Downloads" section before using IP-Phones with Quadro..

ssteiner
10-14-2007, 05:38 PM
Also the phones of 5x seriesare included for the next release.I take it that's the release beyond 4.1.33 which explains why it doesn't work on my Aastra i57 (running the officially latest firmware 2.1.0.2145)

The latest document on Quadro features on supported phones (QuadroFeaturesonEpygiSupportedIPPhonesList-Rev1.1-MedRes.pd f) does not mention anything about paging and Aastra's 5 series (I did check before posting) - I did not check the online help though. I also know to use the PBX features with preference, but you cannot blame me for looking at phone specific features when the PBX provided feature does not work / doesn't really get me where I want to go. Plus in this case, it turns out it's not so much a feature limitation than the proxy touching header fields it's not supposed to touch so experimenting did help locate a problem in the software - and I already did the failure analysis for you including checking the RFC. I don't think that's a negative.

AramK
10-14-2007, 05:56 PM
Sorry, if you understand my comment in a wrong way :) We do not blame anyone. More, you are free to do anything with the phones, we just warn you, that the manual configuration is not desired and it will bring some negative effects. The problems connected to wrong configuration or usage of non-recommended featuresare out of our scope, because we support not the phone's features, but the Quadro features on the phones. Thank you for such interest to our products - we value all the feedbacks from our customers, that helps as to improve our product.


BTW, here in our testlab paging with Aastra5xi series works OK.

ssteiner
02-11-2008, 06:43 AM
@aramk: will the header removal be fixed in a future release? If not, I'd like to hear the argument why this isn't an RFC violation.

AramK
02-11-2008, 07:29 AM
I'll pass this to our SIP developers. They'll answer to all your questions.

AramK
02-11-2008, 07:56 AM
Stephan, sorry for asking :) Did you mean SIP rfc-3162, as it is written in your first comment, or you mean rfc-3261 ? Here is all the information that I've found about Call-Info header in SIP RFC.

rfc-3261

"20.9 Call-Info
The Call-Info header field provides additional information about the
caller or callee, depending on whether it is found in a request or
response. The purpose of the URI is described by the "purpose"
parameter. The "icon" parameter designates an image suitable as an
iconic representation of the caller or callee. The "info" parameter
describes the caller or callee in general, for example, through a web
page. The "card" parameter provides a business card, for example, in
vCard [36] or LDIF [37] formats. Additional tokens can be registered
using IANA and the procedures in Section 27.
Use of the Call-Info header field can pose a security risk. If a
callee fetches the URIs provided by a malicious caller, the callee
may be at risk for displaying inappropriate or offensive content,
dangerous or illegal content, and so on. Therefore, it is
RECOMMENDED that a UA only render the information in the Call-Info
header field if it can verify the authenticity of the element that
originated the header field and trusts that element. This need not
be the peer UA; a proxy can insert this header field into requests.
Example:
Call-Info: <http://wwww.example.com/alice/photo.jpg (http://wwww.example.com/alice/photo.jpg)> ;purpose=icon,
<http://www.example.com/alice/ (http://www.example.com/alice/)> ;purpose=info"

Here are 2 arguments to not use Call-Info header.
1. You can read in text above, that "Use of the Call-Info header field can pose a security risk", and
2. My understanding of the sentence from your first comment "a proxy may not remove a Call-Info header" is that we may or may not remove Call-Info header, as it is not a mandatory field.
so I don't think that Call-Info header removal is a RFC violation.

Anyway, we support Call-Info header in Quadro 5.0.x versions for SLA functionality only.

I already passed your question to our development, maybe they'll have some additions.

ssteiner
02-13-2008, 09:16 AM
I was refering to RFC 3262, section 20.1.

It contains a table listing header fields, where they can used, and what the proxy may do with them.. here's the appropriate line



Call-Info ar - - - o o oar means


a: A proxy can add or concatenate the header field if not present.
r: A proxy must be able to read the header field, and thus this
header field cannot be encrypted.Note that there is no m or d option so the proxy may not modify, nor delete the header if it is there.

And as far as security goes, nothing in the RFC says you can simply delete it.. it just recommends that the UA only render it if it can verify it. So.. it's not up to the proxy but up to the UA to decide what to do with it.. the proxy has no say in this case.

And as far as optional goes.. the header is optional, but if it is there, the proxy must not touch it (it can add it though since the a option is allowed). Forwarding of the existing header element is not optional in this case.. it's optional to the source of an INVITE to put it into the INVITE or not, but unless there's a d in the proxy column, the proxy has no right to remove it.

AramK
02-13-2008, 01:19 PM
Here is addition from our SIP developers to my previous comment.
We haven't traditional proxy in Quadro, it is B2BUA with Quadro Call Manager and the SIP RFC sections related to proxy functionality cannot be applied to Quadro’s B2BUA, so there is no RFC violation.

ssteiner
02-15-2008, 03:34 AM
I'd laugh if this weren't so sad. I'm sorry to see you guys becoming more and more like Linksys. Instead of fixing things, you invent reasons why you shouldn't fix something :(

You can pull this argument out every time to completely pervert the SIP RFCs and claim you're doing nothing wrong. As an engineer, I consider this behavior shameful.

AramK
02-15-2008, 06:41 AM
I'd laugh if this weren't so sad..
Me too, Stephan.


I'm sorry to see you guys becoming more and more like Linksys. Instead of fixing things, you invent reasons why you shouldn't fix something :(
I don't know much about the problems between you and Linksys, but there is nothing to fix here in Quadro regarding this particular "problem". We don't invent any reasons, but just constating the facts. If something isn't work in Quadro according to your desires, it isn't enough to blame the device.


You can pull this argument out every time to completely pervert the SIP RFCs and claim you're doing nothing wrong. As an engineer, I consider this behavior shameful.
Can you please mention just one reference to our whole documentation, where we are declaring that we have a SIP proxy in Quadro ? I'll answer right now - you can't. I have to repeat again, that we have only B2BUA in Quadro and according to SIP RFC's definition UA can do anything with Call-Info header. Instead of accepting obvious truth, you are trying to blame us and find a way to force us to implement something, that maybe will be used only by you. From now on I'd ask you to be more restrained in your comments.

Now let's go back to the roots of this conversation. If you need paging, then Quadro offers paging with Snom and Aastra phones only. You know well how to create Paging Group and how to configure it. You know also what phones are officially declared by Epygi that can be used with Quadro Paging feature and Linksys phones aren't in that list. You can consider this as a Quadro limitation, but we are not planning to support so-called "direct paging". In case if Linksys phones will be officially included into our Supported IP-Phone's list, we'll think about supporting Paging with that phones too.

ssteiner
02-15-2008, 08:03 AM
Look at the definition of what a proxy ies:


Proxy, Proxy Server: An intermediary entity that acts as both a
server and a client for the purpose of making requests on
behalf of other clients. A proxy server primarily plays the
role of routing, which means its job is to ensure that a
request is sent to another entity "closer" to the targeted
user. Proxies are also useful for enforcing policy (for
example, making sure a user is allowed to make a call). A
proxy interprets, and, if necessary, rewrites specific parts of
a request message before forwarding it.

Nothing in the B2BUA definition precludes the proxy function.. in fact both contain the acting as server and client part and shuffling messages back and forth.


Back-to-Back User Agent: A back-to-back user agent (B2BUA) is a
logical entity that receives a request and processes it as a
user agent server (UAS). In order to determine how the request
should be answered, it acts as a user agent client (UAC) and
generates requests. Unlike a proxy server, it maintains dialog
state and must participate in all requests sent on the dialogs
it has established. Since it is a concatenation of a UAC and
UAS, no explicit definitions are needed for its behavior.

The Quadro is also a Registrar, a Redirect Server, a Stateful Proxy and an UA even though that's not mentioned in the documentation either.. but the functionality corresponds to the specification.

And O/T, I wished your PM would get their head out of the sand and realize that if people buy the advanced SIP phones you officially support (specifically Aastra and Snom), you shouldn't preclude them from using the functionality built-into the phone. There's no reason to use a PBX side feature if the phones you bought can do the same thing just as well (if not better) - I doubt many setups are as diverse as mine with so many different manufacturers and thus different handling of the same feature on phone types is not an issue (and that would be the only argument for using a feature PBX-side rather than phone-side).

AramK
02-15-2008, 09:42 AM
I think there is no need to reply to the first part of your comment. Everything is clear from the B2BUA definitions, especially from "B2BUA...processes it as a user agent server ..." and "no explicit definitions are needed for its behavior" parts and I have nothing to add here.
Regarding the last section, I think our management have enough reasons to force the users to use Quadro features instead of using phone's features, in order to have more control, even if "the phones you bought can do the same thing just as well (if not better)", but this is just my opinion. You are free to discuss this directly with our management, not in this forum.

ssteiner
02-18-2008, 06:58 AM
You are free to discuss this directly with our management, not in this forum.If you have me an email address or phone number I'd be happy to..

AramK
02-18-2008, 07:23 AM
The contact details are available in our WEB (http://www.epygi.com/contact-epygi/22/). Also I'll provide this info through PM.

warren
02-18-2008, 11:04 AM
Please feel free to contact me directly regarding this topic. I would be glad to discuss this with you and assist me in getting my head out of the sand. Please call me at your convenience. Thank you.

--Warren