Call Park Presence

Discussion:

Call Park Presence

Bryan Anderson

2012-12-07 18:06:56 UTC

So I noticed some talk in a previous email "Call forward fails to external
number" about the Adtran 900 series. I have a couple of comments and
questions.

We have a TA908e 2nd gen running AOS A5.02.00.E. We currently have not
noticed any issue with having an external caller forwarded to and
externalnumber. cell => user for 30sec
=> external number.

What we have had issues with is presence monitoring of call parking. We
have a Polycom Soundpoint IP 650 with a sing side car that monitors
parklines 6000
- 6003. We can park calls no problem, and so far have not had trouble
retrieving calls. Our problem is that once the call gets retrieved from
the call park the BLF never stops blinking. I have to restart the
Park/Presence servers.

This is with SipXecs 4.4.0.

Thoughts and comments would be appreciated.

-Bryan Anderson

Tony Graziano

2012-12-07 18:12:15 UTC

Permalink

I think it is well known that you should not park or upoark calls using the
BLF button on a Polycom.

Post by Bryan Anderson
So I noticed some talk in a previous email "Call forward fails to
external number" about the Adtran 900 series. I have a couple of comments
and questions.
We have a TA908e 2nd gen running AOS A5.02.00.E. We currently have not
noticed any issue with having an external caller forwarded to and externalnumber. cell => user for 30sec
=> external number.
What we have had issues with is presence monitoring of call parking. We
have a Polycom Soundpoint IP 650 with a sing side car that monitors parklines 6000
- 6003. We can park calls no problem, and so far have not had trouble
retrieving calls. Our problem is that once the call gets retrieved from
the call park the BLF never stops blinking. I have to restart the
Park/Presence servers.
This is with SipXecs 4.4.0.
Thoughts and comments would be appreciated.
-Bryan Anderson
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

--
LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
sip: ***@voice.myitdepartment.net

Helpdesk Customers: http://myhelp.myitdepartment.net
Blog: http://blog.myitdepartment.net

Bryan Anderson

2012-12-07 18:20:29 UTC

Permalink

so, they do not use the button for the parking or unparking. They use
Transfer+ext and *4+ext. The light is only there to indicate weather the
call has been retrieved or not.

-Bryan Anderson

Post by Tony Graziano
I think it is well known that you should not park or upoark calls using
the BLF button on a Polycom.

Post by Bryan Anderson
So I noticed some talk in a previous email "Call forward fails to
external number" about the Adtran 900 series. I have a couple of comments
and questions.
We have a TA908e 2nd gen running AOS A5.02.00.E. We currently have not
noticed any issue with having an external caller forwarded to and
external number. cell => user for 30sec => external number.
What we have had issues with is presence monitoring of call parking. We
have a Polycom Soundpoint IP 650 with a sing side car that monitors parklines 6000
- 6003. We can park calls no problem, and so far have not had trouble
retrieving calls. Our problem is that once the call gets retrieved from
the call park the BLF never stops blinking. I have to restart the
Park/Presence servers.
This is with SipXecs 4.4.0.
Thoughts and comments would be appreciated.
-Bryan Anderson
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

Telephone: 434.984.8426
Helpdesk Customers: http://myhelp.myitdepartment.**net<http://myhelp.myitdepartment.net>
Blog: http://blog.myitdepartment.net
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

Michael Picher

2012-12-07 18:22:46 UTC

Permalink

Also, there are some issues with Adtran's as gateways. Invite w/ Replaces
is what Josh told me. We'd love to see them fix it. Maybe if enough
people complain to them...

Mike

--
Michael Picher, Director of Technical Services
eZuce, Inc.

300 Brickstone Square****

Suite 201****

Andover, MA. 01810
O.978-296-1005 X2015
M.207-956-0262
@mpicher <http://twitter.com/mpicher>
linkedin <http://www.linkedin.com/profile/view?id=35504760&trk=tab_pro>
www.ezuce.com

------------------------------------------------------------------------------------------------------------
"The best way to predict the future is to invent it." - Alan Kay

Ali Ardestani

2012-12-07 19:07:41 UTC

Permalink

This is how we implemented call park with polycom and it works (it is a
workaround though)

1. Extension 700 forwards to 701, 702, 703 and 703

2. added the below to the custom config of the phones (this is done so that
the key does not timeout after 1 minute and call the park orbit directly
<call
call.offeringTimeOut="3600"
call.directedCallPickupMethod="legacy"
call.parkedCallRetrieveMethod="legacy"
3. subscribe to the presence of 700 on user speed dials

4. Make sure you use the bridge, we had problems with the call unparking
when we did not use the bridge for incoming calls from trunk provider

*5. Our firewal does ALG, so we had to uncheck "Use public address for call
setup" under Devices=>Gateways(choose the gw)=>ITSP Account, This fixed our
problem with the calls unparking, maybe your firewall is also doing some
form of ALG*

Bryan Anderson

2012-12-07 19:16:41 UTC

Permalink

Thanks for the reply and I will defiantly test it. We use a T1 for service
into the Adtran and the Adtran is in SipXecs as an unmanaged gateway.

-Bryan Anderson

Post by Ali Ardestani
This is how we implemented call park with polycom and it works (it is a
workaround though)
1. Extension 700 forwards to 701, 702, 703 and 703
2. added the below to the custom config of the phones (this is done so
that the key does not timeout after 1 minute and call the park orbit
directly
<call
call.offeringTimeOut="3600"
call.directedCallPickupMethod="legacy"
call.parkedCallRetrieveMethod="legacy"
3. subscribe to the presence of 700 on user speed dials
4. Make sure you use the bridge, we had problems with the call unparking
when we did not use the bridge for incoming calls from trunk provider
*5. Our firewal does ALG, so we had to uncheck "Use public address for
call setup" under Devices=>Gateways(choose the gw)=>ITSP Account, This
fixed our problem with the calls unparking, maybe your firewall is also
doing some form of ALG*

Post by Bryan Anderson
So I noticed some talk in a previous email "Call forward fails to
external number" about the Adtran 900 series. I have a couple of comments
and questions.
We have a TA908e 2nd gen running AOS A5.02.00.E. We currently have not
noticed any issue with having an external caller forwarded to and
external number. cell => user for 30sec => external number.
What we have had issues with is presence monitoring of call parking. We
have a Polycom Soundpoint IP 650 with a sing side car that monitors parklines 6000
- 6003. We can park calls no problem, and so far have not had trouble
retrieving calls. Our problem is that once the call gets retrieved from
the call park the BLF never stops blinking. I have to restart the
Park/Presence servers.
This is with SipXecs 4.4.0.
Thoughts and comments would be appreciated.
-Bryan Anderson
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

--
--
Ali S Ardestani
Telephony Systems Engineer
Private National Mortgage Acceptance Company (PennyMac)
6101 Condor Drive
Moorpark, CA 93021
(805) 330-6004 Office
(818) 224-7442 x2654 Office
(626) 817-3512 Mobile
(818) 224-7397 Fax
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

Bryan Anderson

2012-12-07 22:16:29 UTC

Permalink

So I pulled some tests and some traces, and have also opened a ticket with
Adtran. Using a Dialog Count I identified the following callid's to be in
reference to one call.

I called into the system with my cell to an alias (1811) on the
extension(5063). I was parked on x6000. Extension 1802 retrieved the call
and then we ended. (4=adtran 5=SipXecs, 181=x5603, 147=x1802)

61 INVITE 2012-12-07T20:05:51
3c0e5b8-7f000001-13c4-2892d7-e3be3276-***@10.0.31.4 => 4311 ->
1811(5063) -> 6000
30 INVITE 2012-12-07T20:06:21
3f55ee95-7ee55086-***@10.0.31.181 => MoH
30 INVITE 2012-12-07T20:06:27
a93cae45-a1b73e76-***@10.0.31.181 => 6000
33 INVITE 2012-12-07T20:06:28
3c0ed38-7f000001-13c4-2892fb-c2bd77a9-***@10.0.31.4 => 6000
30 INVITE 2012-12-07T20:06:51
193ddbd-44cbfc8e-***@10.0.31.147 => 1802 -> 6000 retrieve call
29 INVITE 2012-12-07T20:06:52
3c0eb58-7f000001-13c4-289313-94be59a7-***@10.0.31.4 => (From 1802
retrieving the call) 4311 -> 1802

Where does the BLF for the call park get so it doesn't release? That is
what I am looking for. I am sorry I just don't know the SIP protocol well
enough to find it on my own. I have seen this with Polycom firmwares
3.2.4, 3.2.7 and yes 3.3.0 and 4.0.3(this trace). I have a debug off the
adtran to send to them, but they asked me were it is failing and I just
don't know for sure myself.

-Bryan Anderson

Post by Bryan Anderson
Thanks for the reply and I will defiantly test it. We use a T1 for
service into the Adtran and the Adtran is in SipXecs as an unmanaged
gateway.
-Bryan Anderson

Post by Bryan Anderson
So I noticed some talk in a previous email "Call forward fails to
external number" about the Adtran 900 series. I have a couple of comments
and questions.
We have a TA908e 2nd gen running AOS A5.02.00.E. We currently have not
noticed any issue with having an external caller forwarded to and
external number. cell => user for 30sec => external number.
What we have had issues with is presence monitoring of call parking. We
have a Polycom Soundpoint IP 650 with a sing side car that monitors parklines 6000
- 6003. We can park calls no problem, and so far have not had trouble
retrieving calls. Our problem is that once the call gets retrieved
from the call park the BLF never stops blinking. I have to restart the
Park/Presence servers.
This is with SipXecs 4.4.0.
Thoughts and comments would be appreciated.
-Bryan Anderson
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

Ali Ardestani

2012-12-08 08:19:24 UTC

Permalink

You need to install ngrep and do an ngrep -Wbyline port 5060 to trace sip
messaging

Post by Bryan Anderson
So I pulled some tests and some traces, and have also opened a ticket with
Adtran. Using a Dialog Count I identified the following callid's to be in
reference to one call.
I called into the system with my cell to an alias (1811) on the
extension(5063). I was parked on x6000. Extension 1802 retrieved the call
and then we ended. (4=adtran 5=SipXecs, 181=x5603, 147=x1802)
61 INVITE 2012-12-07T20:05:51
4311 -> 1811(5063) -> 6000
30 INVITE 2012-12-07T20:06:21
30 INVITE 2012-12-07T20:06:27
33 INVITE 2012-12-07T20:06:28
6000
30 INVITE 2012-12-07T20:06:51
29 INVITE 2012-12-07T20:06:52
(From 1802 retrieving the call) 4311 -> 1802
Where does the BLF for the call park get so it doesn't release? That is
what I am looking for. I am sorry I just don't know the SIP protocol well
enough to find it on my own. I have seen this with Polycom firmwares
3.2.4, 3.2.7 and yes 3.3.0 and 4.0.3(this trace). I have a debug off the
adtran to send to them, but they asked me were it is failing and I just
don't know for sure myself.
-Bryan Anderson
Thanks for the reply and I will defiantly test it. We use a T1 for
service into the Adtran and the Adtran is in SipXecs as an unmanaged
gateway.
-Bryan Anderson
This is how we implemented call park with polycom and it works (it is a
workaround though)
1. Extension 700 forwards to 701, 702, 703 and 703
2. added the below to the custom config of the phones (this is done so
that the key does not timeout after 1 minute and call the park orbit
directly
<call
call.offeringTimeOut="3600"
call.directedCallPickupMethod="legacy"
call.parkedCallRetrieveMethod="legacy"
3. subscribe to the presence of 700 on user speed dials
4. Make sure you use the bridge, we had problems with the call unparking
when we did not use the bridge for incoming calls from trunk provider
*5. Our firewal does ALG, so we had to uncheck "Use public address for
call setup" under Devices=>Gateways(choose the gw)=>ITSP Account, This
fixed our problem with the calls unparking, maybe your firewall is also
doing some form of ALG*
So I noticed some talk in a previous email "Call forward fails to
external number" about the Adtran 900 series. I have a couple of comments
and questions.
We have a TA908e 2nd gen running AOS A5.02.00.E. We currently have not
noticed any issue with having an external caller forwarded to and externalnumber. cell => user for 30sec
=> external number.
What we have had issues with is presence monitoring of call parking. We
have a Polycom Soundpoint IP 650 with a sing side car that monitors parklines 6000
- 6003. We can park calls no problem, and so far have not had trouble
retrieving calls. Our problem is that once the call gets retrieved from
the call park the BLF never stops blinking. I have to restart the
Park/Presence servers.
This is with SipXecs 4.4.0.
Thoughts and comments would be appreciated.
-Bryan Anderson
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/
--
--
Ali S Ardestani
Telephony Systems Engineer
Private National Mortgage Acceptance Company (PennyMac)
6101 Condor Drive
Moorpark, CA 93021

Bryan Anderson

2012-12-12 17:12:08 UTC

Permalink

So as I said before I am not well versed in the SIP protocol but this was
Adtrans response.

Thanks Bryan,

I do not believe this to be an ADTRAN issue. The call leg that is being
replaced only exists on that PBX. Check out the Refer message sent to the
ADTRAN:

Rx: UDP src=10.0.31.5:5060 dst=10.0.31.4:5060
18:07:20.905 SIP.STACK MSG REFER sip:10.0.31.4:5060;transport=
UDP SIP/2.0

;tag=NkynMZ

18:07:20.905 SIP.STACK MSG To:
<sip:10.0.31.4>;tag=3bd6630-7f000001-13c4-2e2d5b-dce8ab25-2e2d5b
18:07:20.906 SIP.STACK MSG Call-Id:
3bffb58-7f000001-13c4-2e2d5b-cf3f8dba-***@10.0.31.4
18:07:20.906 SIP.STACK MSG Cseq: 3 REFER
18:07:20.906 SIP.STACK MSG Contact: <sip:***@10.0.31.5:5120
;transport=tcp;x-sipX-nonat>
18:07:20.906 SIP.STACK MSG Referred-By: <sip:***@inwsip.lcsnw.org>
18:07:20.906 SIP.STACK MSG Refer-To: <
sip:***@inwsip.lcsnw.org?REPLACES=a5320d9d-1d788972-8a9aa6d3%4010.0.27.106%3Bto-tag%3D1C951DC1-EB497A86%3Bfrom-tag%3Drp_5OC&REQUIRE=replaces&X-sipX-Authidentity=%3Csip%3A%7E%7Eid%7Epark%40inwsip.lcsnw.org%3Bsignature%3D50C7E6D8%253A%253A05936d0a35fdf946cde62d9a14e3e446%3E&REFERENCES=3bffb58-7f000001-13c4-2e2d5b-cf3f8dba-2e2d5b%4010.0.31.4%3Brel%3Drefer
18:07:20.906 SIP.STACK MSG References:
a5320d9d-1d788972-***@10.0.27.106;rel=xfer
18:07:20.907 SIP.STACK MSG Date: Wed, 12 Dec 2012 02:07:20 GMT
18:07:20.907 SIP.STACK MSG Max-Forwards: 19
18:07:20.907 SIP.STACK MSG User-Agent: sipXecs/4.4.0 sipXecs/park
(Linux)
18:07:20.907 SIP.STACK MSG Accept-Language: en
18:07:20.907 SIP.STACK MSG Allow: INVITE, ACK, CANCEL, BYE, REFER,
OPTIONS, NOTIFY, SUBSCRIBE
18:07:20.907 SIP.STACK MSG Supported: replaces

Below is the Refer To from that message:

Refer-To: <
sip:***@inwsip.lcsnw.org?REPLACES=a5320d9d-1d788972-8a9aa6d3%4010.0.27.106%3Bto-tag%3D1C951DC1-EB497A86%3Bfrom-tag%3Drp_5OC&REQUIRE=replaces&X-sipX-Authidentity=%3Csip%3A%7E%7Eid%7Epark%40inwsip.lcsnw.org%3Bsignature%3D50C7E6D8%253A%253A05936d0a35fdf946cde62d9a14e3e446%3E&REFERENCES=3bffb58-7f000001-13c4-2e2d5b-cf3f8dba-2e2d5b%4010.0.31.4%3Brel%3Drefer
The call-id is not seen anywhere else in this debug meaning, that portion
of the call is not on the ADTRAN. The ADTRAN accepts the Refer to it is up
to the other device to tear that call down.

Regards,
Geoff

-Bryan Anderson

You need to install ngrep and do an ngrep -Wbyline port 5060 to trace sip
messaging

Post by Bryan Anderson
So I pulled some tests and some traces, and have also opened a ticket
with Adtran. Using a Dialog Count I identified the following callid's to
be in reference to one call.
I called into the system with my cell to an alias (1811) on the
extension(5063). I was parked on x6000. Extension 1802 retrieved the call
and then we ended. (4=adtran 5=SipXecs, 181=x5603, 147=x1802)
61 INVITE 2012-12-07T20:05:51
1811(5063) -> 6000
30 INVITE 2012-12-07T20:06:21
30 INVITE 2012-12-07T20:06:27
33 INVITE 2012-12-07T20:06:28
30 INVITE 2012-12-07T20:06:51
29 INVITE 2012-12-07T20:06:52
retrieving the call) 4311 -> 1802
Where does the BLF for the call park get so it doesn't release? That is
what I am looking for. I am sorry I just don't know the SIP protocol well
enough to find it on my own. I have seen this with Polycom firmwares
3.2.4, 3.2.7 and yes 3.3.0 and 4.0.3(this trace). I have a debug off the
adtran to send to them, but they asked me were it is failing and I just
don't know for sure myself.
-Bryan Anderson
Thanks for the reply and I will defiantly test it. We use a T1 for
service into the Adtran and the Adtran is in SipXecs as an unmanaged
gateway.
-Bryan Anderson
This is how we implemented call park with polycom and it works (it is a
workaround though)
1. Extension 700 forwards to 701, 702, 703 and 703
2. added the below to the custom config of the phones (this is done so
that the key does not timeout after 1 minute and call the park orbit
directly
<call
call.offeringTimeOut="3600"
call.directedCallPickupMethod="legacy"
call.parkedCallRetrieveMethod="legacy"
3. subscribe to the presence of 700 on user speed dials
4. Make sure you use the bridge, we had problems with the call unparking
when we did not use the bridge for incoming calls from trunk provider
*5. Our firewal does ALG, so we had to uncheck "Use public address for
call setup" under Devices=>Gateways(choose the gw)=>ITSP Account, This
fixed our problem with the calls unparking, maybe your firewall is also
doing some form of ALG*
So I noticed some talk in a previous email "Call forward fails to
external number" about the Adtran 900 series. I have a couple of comments
and questions.
We have a TA908e 2nd gen running AOS A5.02.00.E. We currently have not
noticed any issue with having an external caller forwarded to and
external number. cell => user for 30sec => external number.
What we have had issues with is presence monitoring of call parking. We
have a Polycom Soundpoint IP 650 with a sing side car that monitors parklines 6000
- 6003. We can park calls no problem, and so far have not had trouble
retrieving calls. Our problem is that once the call gets retrieved from
the call park the BLF never stops blinking. I have to restart the
Park/Presence servers.
This is with SipXecs 4.4.0.
Thoughts and comments would be appreciated.
-Bryan Anderson
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/
--
--
Ali S Ardestani
Telephony Systems Engineer
Private National Mortgage Acceptance Company (PennyMac)
6101 Condor Drive
Moorpark, CA 93021

Josh Patten

2012-12-12 20:15:20 UTC

Permalink

It looks like Adtran and Digium are screaming the same thing. I'm going to
post the response I sent to Digium:

According to http://tools.ietf.org/html/rfc5589#page-26 (see the refer-to
on page 27) this is a valid transfer scenario. I have attached a valid
capture using FreeSWITCH as a gateway, and when the particular REFER that
is giving the Adtran GW problems comes up, it simply performs the refer and
marks the replaces in the INVITE (see highlights):

REFER sip:gw+***@172.16.1.90:5080;transport=udp;gw=
sip.corp.ezuce.com SIP/2.0
From: <sip:***@sip.corp.ezuce.com>;tag=4Ut224
To: "4092330016"<sip:~~id~***@sip.corp.ezuce.com>;tag=Se415mQNX7D7D
Call-Id: 4d339693-a499-1230-729f-fad9dc40d221
Cseq: 3 REFER
Contact: <sip:***@172.16.1.5:5120;transport=tcp;x-sipX-nonat>
Referred-By: <sip:***@sip.corp.ezuce.com>
Refer-To: <*sip:***@sip.corp.ezuce.com?**
REPLACES=a0511239-ab6decb2-99d54f8f%40172.16.1.51%3Bto-tag%3DCA50B7BD-573B246%3Bfrom-tag%3DLkTYH8&REQUIRE=replaces&X-sipX-Authidentity=%3Csip%3A%7E%7Eid%7Epark%
40sip.corp.ezuce.com
%3Bsignature%3D509C36D7%253A%253Ad1b624445c9e26173fe0de17f291d62d%3E&REFERENCES=4d339693-a499-1230-729f-fad9dc40d221%3Brel%3Drefer
*>
References: a0511239-ab6decb2-***@172.16.1.51;rel=xfer
Date: Thu, 08 Nov 2012 22:48:55 GMT
Max-Forwards: 19
User-Agent: sipXecs/4.6.0 sipXecs/park (Linux)
Accept-Language: en
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE
Supported: replaces
Proxy-Authorization: Digest username="~~id~park", realm="sip.corp.ezuce.com",
nonce="5c81f6a19cf6bd3bcaefdfe726e2db2e509c36d7",
uri="sip:gw+***@172.16.1.90:5080;transport=udp;gw=
sip.corp.ezuce.com", response="a8fdc3b3eeb0f5e52ef91342aba9df3f",
cnonce="jbJLTS", qop=auth, nc=00000001
Via: SIP/2.0/UDP 172.16.1.5;branch=z9hG4bK-XX-0b96Qj3NNqiD6usxS_3GIL_emg
Via: SIP/2.0/TCP 172.16.1.5:5120
;branch=z9hG4bK-XX-003aW8u6STjzakMVEqA5D65UPg;id=18008-29
Content-Length: 0

SIP/2.0 202 Accepted
Via: SIP/2.0/UDP 172.16.1.5;branch=z9hG4bK-XX-0b96Qj3NNqiD6usxS_3GIL_emg
Via: SIP/2.0/TCP 172.16.1.5:5120
;branch=z9hG4bK-XX-003aW8u6STjzakMVEqA5D65UPg;id=18008-29
From: <sip:***@sip.corp.ezuce.com>;tag=4Ut224
To: "4092330016" <sip:~~id~***@sip.corp.ezuce.com>;tag=Se415mQNX7D7D
Call-ID: 4d339693-a499-1230-729f-fad9dc40d221
CSeq: 3 REFER
Contact: <sip:gw+***@172.16.1.90:5080;transport=udp;gw=
sip.corp.ezuce.com>
Expires: 60
User-Agent: FreeSWITCH-mod_sofia/1.2.3
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER,
REFER, NOTIFY
Supported: timer, precondition, path, replaces
Allow-Events: talk, hold, conference, refer
Content-Length: 0

INVITE *sip:***@sip.corp.ezuce.com* SIP/2.0
Via: SIP/2.0/UDP 172.16.1.90:5080;rport;branch=z9hG4bK2pQyFrXy5e8mN
Max-Forwards: 70
From: "4092330016" <sip:***@172.16.1.90>;tag=tQXt7F8rtg4SS
To: <sip:***@sip.corp.ezuce.com>
Call-ID: 50251028-a499-1230-729f-fad9dc40d221
CSeq: 35871402 INVITE
Contact: <sip:***@172.16.1.90:5080>
User-Agent: FreeSWITCH-mod_sofia/1.2.3
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER,
REFER, NOTIFY
*Require: replaces*
Supported: timer, precondition, path, replaces
Allow-Events: talk, hold, conference, refer
*Replaces: a0511239-ab6decb2-***@172.16.1.51
;to-tag=CA50B7BD-573B246;from-tag=LkTYH8*
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 255
X-FS-Support: update_display,send_info
*X-sipX-Authidentity: <sip:~~id~***@sip.corp.ezuce.com
;signature=509C36D7%3A%3Ad1b624445c9e26173fe0de17f291d62d>
REFERENCES: 4d339693-a499-1230-729f-fad9dc40d221;rel=refer

;party=calling;screen=yes;privacy=off

Obviously the Adtran will not have knowledge of it, it's a call dialog on a
completely different SIP client. Refer-To does not use existing dialogs to
perform REFER. This is allowed per RFC 3515:

2.4.3 Accessing the Referred-to Resource

The resource identified by the Refer-To URI is contacted using the
normal mechanisms for that URI type. For example, if the URI is a
SIP URI indicating INVITE (using a method=INVITE URI parameter for
example), the UA would issue a new INVITE using all of the normal
rules for sending an INVITE defined in [1].

So as I said before I am not well versed in the SIP protocol but this was
Adtrans response.
Thanks Bryan,
I do not believe this to be an ADTRAN issue. The call leg that is being
replaced only exists on that PBX. Check out the Refer message sent to the
Rx: UDP src=10.0.31.5:5060 dst=10.0.31.4:5060
18:07:20.905 SIP.STACK MSG REFER sip:10.0.31.4:5060;transport=
UDP SIP/2.0

;tag=NkynMZ

<sip:10.0.31.4>;tag=3bd6630-7f000001-13c4-2e2d5b-dce8ab25-2e2d5b
18:07:20.906 SIP.STACK MSG Cseq: 3 REFER
;transport=tcp;x-sipX-nonat>
18:07:20.906 SIP.STACK MSG Refer-To: <
18:07:20.907 SIP.STACK MSG Date: Wed, 12 Dec 2012 02:07:20 GMT
18:07:20.907 SIP.STACK MSG Max-Forwards: 19
18:07:20.907 SIP.STACK MSG User-Agent: sipXecs/4.4.0 sipXecs/park
(Linux)
18:07:20.907 SIP.STACK MSG Accept-Language: en
18:07:20.907 SIP.STACK MSG Allow: INVITE, ACK, CANCEL, BYE, REFER,
OPTIONS, NOTIFY, SUBSCRIBE
18:07:20.907 SIP.STACK MSG Supported: replaces
Refer-To: <
The call-id is not seen anywhere else in this debug meaning, that portion
of the call is not on the ADTRAN. The ADTRAN accepts the Refer to it is up
to the other device to tear that call down.
Regards,
Geoff
-Bryan Anderson

You need to install ngrep and do an ngrep -Wbyline port 5060 to trace
sip messaging

Post by Bryan Anderson
So I pulled some tests and some traces, and have also opened a ticket
with Adtran. Using a Dialog Count I identified the following callid's to
be in reference to one call.
I called into the system with my cell to an alias (1811) on the
extension(5063). I was parked on x6000. Extension 1802 retrieved the call
and then we ended. (4=adtran 5=SipXecs, 181=x5603, 147=x1802)
61 INVITE 2012-12-07T20:05:51
1811(5063) -> 6000
30 INVITE 2012-12-07T20:06:21
30 INVITE 2012-12-07T20:06:27
33 INVITE 2012-12-07T20:06:28
30 INVITE 2012-12-07T20:06:51
29 INVITE 2012-12-07T20:06:52
retrieving the call) 4311 -> 1802
Where does the BLF for the call park get so it doesn't release? That is
what I am looking for. I am sorry I just don't know the SIP protocol well
enough to find it on my own. I have seen this with Polycom firmwares
3.2.4, 3.2.7 and yes 3.3.0 and 4.0.3(this trace). I have a debug off the
adtran to send to them, but they asked me were it is failing and I just
don't know for sure myself.
-Bryan Anderson
Thanks for the reply and I will defiantly test it. We use a T1 for
service into the Adtran and the Adtran is in SipXecs as an unmanaged
gateway.
-Bryan Anderson
This is how we implemented call park with polycom and it works (it is a
workaround though)
1. Extension 700 forwards to 701, 702, 703 and 703
2. added the below to the custom config of the phones (this is done so
that the key does not timeout after 1 minute and call the park orbit
directly
<call
call.offeringTimeOut="3600"
call.directedCallPickupMethod="legacy"
call.parkedCallRetrieveMethod="legacy"
3. subscribe to the presence of 700 on user speed dials
4. Make sure you use the bridge, we had problems with the call unparking
when we did not use the bridge for incoming calls from trunk provider
*5. Our firewal does ALG, so we had to uncheck "Use public address for
call setup" under Devices=>Gateways(choose the gw)=>ITSP Account, This
fixed our problem with the calls unparking, maybe your firewall is also
doing some form of ALG*
So I noticed some talk in a previous email "Call forward fails to
external number" about the Adtran 900 series. I have a couple of comments
and questions.
We have a TA908e 2nd gen running AOS A5.02.00.E. We currently have not
noticed any issue with having an external caller forwarded to and
external number. cell => user for 30sec => external number.
What we have had issues with is presence monitoring of call parking. We
have a Polycom Soundpoint IP 650 with a sing side car that monitors parklines 6000
- 6003. We can park calls no problem, and so far have not had trouble
retrieving calls. Our problem is that once the call gets retrieved
from the call park the BLF never stops blinking. I have to restart the
Park/Presence servers.
This is with SipXecs 4.4.0.
Thoughts and comments would be appreciated.
-Bryan Anderson
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/
--
--
Ali S Ardestani
Telephony Systems Engineer
Private National Mortgage Acceptance Company (PennyMac)
6101 Condor Drive
Moorpark, CA 93021

_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

--
Josh Patten
eZuce
Solutions Architect
O.978-296-1005 X2050
M.979-574-5699
http://www.ezuce.com

Tony Graziano

2012-12-12 20:40:52 UTC

Permalink

REFER has been around a while, not everyone supports it in a way that makes
sense (per the RFC).

If REFER is supported, the accused scenario will work. If it is not
supported an SBC that can hold the refer locally and bridge the call legs
together and manage the transfers is required.

The question to both Adtran and Digium is the same: Do you support RFC-3515
(REFER) in product x. Which is exactly what Josh seems to have asked.

Go Josh!

Post by Josh Patten
It looks like Adtran and Digium are screaming the same thing. I'm going to
According to http://tools.ietf.org/html/rfc5589#page-26 (see the refer-to
on page 27) this is a valid transfer scenario. I have attached a valid
capture using FreeSWITCH as a gateway, and when the particular REFER that
is giving the Adtran GW problems comes up, it simply performs the refer
sip.corp.ezuce.com SIP/2.0
Call-Id: 4d339693-a499-1230-729f-fad9dc40d221
Cseq: 3 REFER
REPLACES=a0511239-ab6decb2-99d54f8f%40172.16.1.51%3Bto-tag%3DCA50B7BD-573B246%3Bfrom-tag%3DLkTYH8&REQUIRE=replaces&X-sipX-Authidentity=%3Csip%3A%7E%7Eid%7Epark%
40sip.corp.ezuce.com
%3Bsignature%3D509C36D7%253A%253Ad1b624445c9e26173fe0de17f291d62d%3E&REFERENCES=4d339693-a499-1230-729f-fad9dc40d221%3Brel%3Drefer
*>
Date: Thu, 08 Nov 2012 22:48:55 GMT
Max-Forwards: 19
User-Agent: sipXecs/4.6.0 sipXecs/park (Linux)
Accept-Language: en
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE
Supported: replaces
Proxy-Authorization: Digest username="~~id~park", realm="
sip.corp.ezuce.com", nonce="5c81f6a19cf6bd3bcaefdfe726e2db2e509c36d7",
sip.corp.ezuce.com", response="a8fdc3b3eeb0f5e52ef91342aba9df3f",
cnonce="jbJLTS", qop=auth, nc=00000001
Via: SIP/2.0/UDP 172.16.1.5;branch=z9hG4bK-XX-0b96Qj3NNqiD6usxS_3GIL_emg
Via: SIP/2.0/TCP 172.16.1.5:5120
;branch=z9hG4bK-XX-003aW8u6STjzakMVEqA5D65UPg;id=18008-29
Content-Length: 0
SIP/2.0 202 Accepted
Via: SIP/2.0/UDP 172.16.1.5;branch=z9hG4bK-XX-0b96Qj3NNqiD6usxS_3GIL_emg
Via: SIP/2.0/TCP 172.16.1.5:5120
;branch=z9hG4bK-XX-003aW8u6STjzakMVEqA5D65UPg;id=18008-29
Call-ID: 4d339693-a499-1230-729f-fad9dc40d221
CSeq: 3 REFER
sip.corp.ezuce.com>
Expires: 60
User-Agent: FreeSWITCH-mod_sofia/1.2.3
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER,
REFER, NOTIFY
Supported: timer, precondition, path, replaces
Allow-Events: talk, hold, conference, refer
Content-Length: 0
Via: SIP/2.0/UDP 172.16.1.90:5080;rport;branch=z9hG4bK2pQyFrXy5e8mN
Max-Forwards: 70
Call-ID: 50251028-a499-1230-729f-fad9dc40d221
CSeq: 35871402 INVITE
User-Agent: FreeSWITCH-mod_sofia/1.2.3
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER,
REFER, NOTIFY
*Require: replaces*
Supported: timer, precondition, path, replaces
Allow-Events: talk, hold, conference, refer
;to-tag=CA50B7BD-573B246;from-tag=LkTYH8*
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 255
X-FS-Support: update_display,send_info
;signature=509C36D7%3A%3Ad1b624445c9e26173fe0de17f291d62d>
REFERENCES: 4d339693-a499-1230-729f-fad9dc40d221;rel=refer

;party=calling;screen=yes;privacy=off

Obviously the Adtran will not have knowledge of it, it's a call dialog on
a completely different SIP client. Refer-To does not use existing dialogs
2.4.3 Accessing the Referred-to Resource
The resource identified by the Refer-To URI is contacted using the
normal mechanisms for that URI type. For example, if the URI is a
SIP URI indicating INVITE (using a method=INVITE URI parameter for
example), the UA would issue a new INVITE using all of the normal
rules for sending an INVITE defined in [1].

So as I said before I am not well versed in the SIP protocol but this was
Adtrans response.
Thanks Bryan,
I do not believe this to be an ADTRAN issue. The call leg that is being
replaced only exists on that PBX. Check out the Refer message sent to the
Rx: UDP src=10.0.31.5:5060 dst=10.0.31.4:5060
18:07:20.905 SIP.STACK MSG REFER sip:10.0.31.4:5060;transport=
UDP SIP/2.0

;tag=NkynMZ

<sip:10.0.31.4>;tag=3bd6630-7f000001-13c4-2e2d5b-dce8ab25-2e2d5b
18:07:20.906 SIP.STACK MSG Cseq: 3 REFER
;transport=tcp;x-sipX-nonat>
18:07:20.906 SIP.STACK MSG Referred-By: <
18:07:20.906 SIP.STACK MSG Refer-To: <
18:07:20.907 SIP.STACK MSG Date: Wed, 12 Dec 2012 02:07:20 GMT
18:07:20.907 SIP.STACK MSG Max-Forwards: 19
18:07:20.907 SIP.STACK MSG User-Agent: sipXecs/4.4.0 sipXecs/park
(Linux)
18:07:20.907 SIP.STACK MSG Accept-Language: en
18:07:20.907 SIP.STACK MSG Allow: INVITE, ACK, CANCEL, BYE,
REFER, OPTIONS, NOTIFY, SUBSCRIBE
18:07:20.907 SIP.STACK MSG Supported: replaces
Refer-To: <
The call-id is not seen anywhere else in this debug meaning, that portion
of the call is not on the ADTRAN. The ADTRAN accepts the Refer to it is up
to the other device to tear that call down.
Regards,
Geoff
-Bryan Anderson

You need to install ngrep and do an ngrep -Wbyline port 5060 to trace
sip messaging

Post by Bryan Anderson
So I pulled some tests and some traces, and have also opened a ticket
with Adtran. Using a Dialog Count I identified the following callid's to
be in reference to one call.
I called into the system with my cell to an alias (1811) on the
extension(5063). I was parked on x6000. Extension 1802 retrieved the call
and then we ended. (4=adtran 5=SipXecs, 181=x5603, 147=x1802)
61 INVITE 2012-12-07T20:05:51
1811(5063) -> 6000
30 INVITE 2012-12-07T20:06:21
30 INVITE 2012-12-07T20:06:27
33 INVITE 2012-12-07T20:06:28
30 INVITE 2012-12-07T20:06:51
29 INVITE 2012-12-07T20:06:52
retrieving the call) 4311 -> 1802
Where does the BLF for the call park get so it doesn't release? That
is what I am looking for. I am sorry I just don't know the SIP protocol
well enough to find it on my own. I have seen this with Polycom firmwares
3.2.4, 3.2.7 and yes 3.3.0 and 4.0.3(this trace). I have a debug off the
adtran to send to them, but they asked me were it is failing and I just
don't know for sure myself.
-Bryan Anderson
Thanks for the reply and I will defiantly test it. We use a T1 for
service into the Adtran and the Adtran is in SipXecs as an unmanaged
gateway.
-Bryan Anderson
This is how we implemented call park with polycom and it works (it is a
workaround though)
1. Extension 700 forwards to 701, 702, 703 and 703
2. added the below to the custom config of the phones (this is done so
that the key does not timeout after 1 minute and call the park orbit
directly
<call
call.offeringTimeOut="3600"
call.directedCallPickupMethod="legacy"
call.parkedCallRetrieveMethod="legacy"
3. subscribe to the presence of 700 on user speed dials
4. Make sure you use the bridge, we had problems with the call
unparking when we did not use the bridge for incoming calls from trunk
provider
*5. Our firewal does ALG, so we had to uncheck "Use public address for
call setup" under Devices=>Gateways(choose the gw)=>ITSP Account, This
fixed our problem with the calls unparking, maybe your firewall is also
doing some form of ALG*
So I noticed some talk in a previous email "Call forward fails to
external number" about the Adtran 900 series. I have a couple of comments
and questions.
We have a TA908e 2nd gen running AOS A5.02.00.E. We currently have
not noticed any issue with having an external caller forwarded to and
external number. cell => user for 30sec => external number.
What we have had issues with is presence monitoring of call parking. We
have a Polycom Soundpoint IP 650 with a sing side car that monitors
park lines 6000 - 6003. We can park calls no problem, and so far have
not had trouble retrieving calls. Our problem is that once the call
gets retrieved from the call park the BLF never stops blinking. I
have to restart the Park/Presence servers.
This is with SipXecs 4.4.0.
Thoughts and comments would be appreciated.
-Bryan Anderson
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/
--
--
Ali S Ardestani
Telephony Systems Engineer
Private National Mortgage Acceptance Company (PennyMac)
6101 Condor Drive
Moorpark, CA 93021

_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

--
Josh Patten
eZuce
Solutions Architect
O.978-296-1005 X2050
M.979-574-5699
http://www.ezuce.com
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: ***@voice.myitdepartment.net
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
Linked-In Profile:
http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4
Ask about our Internet Fax services!
~~~~~~~~~~~~~~~~~~

Using or developing for sipXecs from SIPFoundry? Ask me about sipX-CoLab
2013!
<http://sipxcolab2013.eventbrite.com/?discount=tony2013>

Josh Patten

2012-12-12 22:23:24 UTC

Permalink

With all the interop testing I've had to do I've become pretty good at
picking things like this out and calling their bluff. Thanks Tony!

Post by Tony Graziano
REFER has been around a while, not everyone supports it in a way that
makes sense (per the RFC).
If REFER is supported, the accused scenario will work. If it is not
supported an SBC that can hold the refer locally and bridge the call legs
together and manage the transfers is required.
The question to both Adtran and Digium is the same: Do you support
RFC-3515 (REFER) in product x. Which is exactly what Josh seems to have
asked.
Go Josh!

Post by Josh Patten
It looks like Adtran and Digium are screaming the same thing. I'm going
According to http://tools.ietf.org/html/rfc5589#page-26 (see the
refer-to on page 27) this is a valid transfer scenario. I have attached a
valid capture using FreeSWITCH as a gateway, and when the particular REFER
that is giving the Adtran GW problems comes up, it simply performs the
sip.corp.ezuce.com SIP/2.0
Call-Id: 4d339693-a499-1230-729f-fad9dc40d221
Cseq: 3 REFER
REPLACES=a0511239-ab6decb2-99d54f8f%40172.16.1.51%3Bto-tag%3DCA50B7BD-573B246%3Bfrom-tag%3DLkTYH8&REQUIRE=replaces&X-sipX-Authidentity=%3Csip%3A%7E%7Eid%7Epark%
40sip.corp.ezuce.com
%3Bsignature%3D509C36D7%253A%253Ad1b624445c9e26173fe0de17f291d62d%3E&REFERENCES=4d339693-a499-1230-729f-fad9dc40d221%3Brel%3Drefer
*>
Date: Thu, 08 Nov 2012 22:48:55 GMT
Max-Forwards: 19
User-Agent: sipXecs/4.6.0 sipXecs/park (Linux)
Accept-Language: en
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE
Supported: replaces
Proxy-Authorization: Digest username="~~id~park", realm="
sip.corp.ezuce.com", nonce="5c81f6a19cf6bd3bcaefdfe726e2db2e509c36d7",
sip.corp.ezuce.com", response="a8fdc3b3eeb0f5e52ef91342aba9df3f",
cnonce="jbJLTS", qop=auth, nc=00000001
Via: SIP/2.0/UDP 172.16.1.5;branch=z9hG4bK-XX-0b96Qj3NNqiD6usxS_3GIL_emg
Via: SIP/2.0/TCP 172.16.1.5:5120
;branch=z9hG4bK-XX-003aW8u6STjzakMVEqA5D65UPg;id=18008-29
Content-Length: 0
SIP/2.0 202 Accepted
Via: SIP/2.0/UDP 172.16.1.5;branch=z9hG4bK-XX-0b96Qj3NNqiD6usxS_3GIL_emg
Via: SIP/2.0/TCP 172.16.1.5:5120
;branch=z9hG4bK-XX-003aW8u6STjzakMVEqA5D65UPg;id=18008-29
Call-ID: 4d339693-a499-1230-729f-fad9dc40d221
CSeq: 3 REFER
sip.corp.ezuce.com>
Expires: 60
User-Agent: FreeSWITCH-mod_sofia/1.2.3
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE,
REGISTER, REFER, NOTIFY
Supported: timer, precondition, path, replaces
Allow-Events: talk, hold, conference, refer
Content-Length: 0
Via: SIP/2.0/UDP 172.16.1.90:5080;rport;branch=z9hG4bK2pQyFrXy5e8mN
Max-Forwards: 70
Call-ID: 50251028-a499-1230-729f-fad9dc40d221
CSeq: 35871402 INVITE
User-Agent: FreeSWITCH-mod_sofia/1.2.3
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE,
REGISTER, REFER, NOTIFY
*Require: replaces*
Supported: timer, precondition, path, replaces
Allow-Events: talk, hold, conference, refer
;to-tag=CA50B7BD-573B246;from-tag=LkTYH8*
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 255
X-FS-Support: update_display,send_info
;signature=509C36D7%3A%3Ad1b624445c9e26173fe0de17f291d62d>
REFERENCES: 4d339693-a499-1230-729f-fad9dc40d221;rel=refer

;party=calling;screen=yes;privacy=off

So as I said before I am not well versed in the SIP protocol but this
was Adtrans response.
Thanks Bryan,
I do not believe this to be an ADTRAN issue. The call leg that is being
replaced only exists on that PBX. Check out the Refer message sent to the
Rx: UDP src=10.0.31.5:5060 dst=10.0.31.4:5060
18:07:20.905 SIP.STACK MSG REFER sip:10.0.31.4:5060;transport=
UDP SIP/2.0

;tag=NkynMZ

<sip:10.0.31.4>;tag=3bd6630-7f000001-13c4-2e2d5b-dce8ab25-2e2d5b
18:07:20.906 SIP.STACK MSG Cseq: 3 REFER
;transport=tcp;x-sipX-nonat>
18:07:20.906 SIP.STACK MSG Referred-By: <
18:07:20.906 SIP.STACK MSG Refer-To: <
18:07:20.907 SIP.STACK MSG Date: Wed, 12 Dec 2012 02:07:20 GMT
18:07:20.907 SIP.STACK MSG Max-Forwards: 19
18:07:20.907 SIP.STACK MSG User-Agent: sipXecs/4.4.0
sipXecs/park (Linux)
18:07:20.907 SIP.STACK MSG Accept-Language: en
18:07:20.907 SIP.STACK MSG Allow: INVITE, ACK, CANCEL, BYE,
REFER, OPTIONS, NOTIFY, SUBSCRIBE
18:07:20.907 SIP.STACK MSG Supported: replaces
Refer-To: <
The call-id is not seen anywhere else in this debug meaning, that
portion of the call is not on the ADTRAN. The ADTRAN accepts the Refer to
it is up to the other device to tear that call down.
Regards,
Geoff
-Bryan Anderson

You need to install ngrep and do an ngrep -Wbyline port 5060 to trace
sip messaging

Post by Bryan Anderson
So I pulled some tests and some traces, and have also opened a ticket
with Adtran. Using a Dialog Count I identified the following callid's to
be in reference to one call.
I called into the system with my cell to an alias (1811) on the
extension(5063). I was parked on x6000. Extension 1802 retrieved the call
and then we ended. (4=adtran 5=SipXecs, 181=x5603, 147=x1802)
61 INVITE 2012-12-07T20:05:51
1811(5063) -> 6000
30 INVITE 2012-12-07T20:06:21
30 INVITE 2012-12-07T20:06:27
33 INVITE 2012-12-07T20:06:28
30 INVITE 2012-12-07T20:06:51
29 INVITE 2012-12-07T20:06:52
retrieving the call) 4311 -> 1802
Where does the BLF for the call park get so it doesn't release? That
is what I am looking for. I am sorry I just don't know the SIP protocol
well enough to find it on my own. I have seen this with Polycom firmwares
3.2.4, 3.2.7 and yes 3.3.0 and 4.0.3(this trace). I have a debug off the
adtran to send to them, but they asked me were it is failing and I just
don't know for sure myself.
-Bryan Anderson
Thanks for the reply and I will defiantly test it. We use a T1 for
service into the Adtran and the Adtran is in SipXecs as an unmanaged
gateway.
-Bryan Anderson
On Fri, Dec 7, 2012 at 11:07 AM, Ali Ardestani <
This is how we implemented call park with polycom and it works (it is
a workaround though)
1. Extension 700 forwards to 701, 702, 703 and 703
2. added the below to the custom config of the phones (this is done so
that the key does not timeout after 1 minute and call the park orbit
directly
<call
call.offeringTimeOut="3600"
call.directedCallPickupMethod="legacy"
call.parkedCallRetrieveMethod="legacy"
3. subscribe to the presence of 700 on user speed dials
4. Make sure you use the bridge, we had problems with the call
unparking when we did not use the bridge for incoming calls from trunk
provider
*5. Our firewal does ALG, so we had to uncheck "Use public address
for call setup" under Devices=>Gateways(choose the gw)=>ITSP Account, This
fixed our problem with the calls unparking, maybe your firewall is also
doing some form of ALG*
So I noticed some talk in a previous email "Call forward fails to
external number" about the Adtran 900 series. I have a couple of comments
and questions.
We have a TA908e 2nd gen running AOS A5.02.00.E. We currently have
not noticed any issue with having an external caller forwarded to and
external number. cell => user for 30sec => external number.
What we have had issues with is presence monitoring of call
parking. We have a Polycom Soundpoint IP 650 with a sing side car
that monitors park lines 6000 - 6003. We can park calls no problem,
and so far have not had trouble retrieving calls. Our problem is that
once the call gets retrieved from the call park the BLF never stops
blinking. I have to restart the Park/Presence servers.
This is with SipXecs 4.4.0.
Thoughts and comments would be appreciated.
-Bryan Anderson
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/
--
--
Ali S Ardestani
Telephony Systems Engineer
Private National Mortgage Acceptance Company (PennyMac)
6101 Condor Drive
Moorpark, CA 93021

_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4
Ask about our Internet Fax services!
~~~~~~~~~~~~~~~~~~
Using or developing for sipXecs from SIPFoundry? Ask me about sipX-CoLab
2013!
<http://sipxcolab2013.eventbrite.com/?discount=tony2013>
Telephone: 434.984.8426
Helpdesk Customers: http://myhelp.myitdepartment.**net<http://myhelp.myitdepartment.net>
Blog: http://blog.myitdepartment.net
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

--
Josh Patten
eZuce
Solutions Architect
O.978-296-1005 X2050
M.979-574-5699
http://www.ezuce.com

Josh Patten

2012-12-12 22:33:59 UTC

Permalink

Try sending them my response to the mailing list and see where that gets
you. If they balk at it, then I'll see how I can explain it better to them.

Post by Josh Patten
With all the interop testing I've had to do I've become pretty good at
picking things like this out and calling their bluff. Thanks Tony!
On Wed, Dec 12, 2012 at 2:40 PM, Tony Graziano <

;party=calling;screen=yes;privacy=off

Obviously the Adtran will not have knowledge of it, it's a call dialog
on a completely different SIP client. Refer-To does not use existing
2.4.3 Accessing the Referred-to Resource
The resource identified by the Refer-To URI is contacted using the
normal mechanisms for that URI type. For example, if the URI is a
SIP URI indicating INVITE (using a method=INVITE URI parameter for
example), the UA would issue a new INVITE using all of the normal
rules for sending an INVITE defined in [1].

So as I said before I am not well versed in the SIP protocol but this
was Adtrans response.
Thanks Bryan,
I do not believe this to be an ADTRAN issue. The call leg that is
being replaced only exists on that PBX. Check out the Refer message sent
Rx: UDP src=10.0.31.5:5060 dst=10.0.31.4:5060
18:07:20.905 SIP.STACK MSG REFER sip:10.0.31.4:5060;transport=
UDP SIP/2.0

;tag=NkynMZ

<sip:10.0.31.4>;tag=3bd6630-7f000001-13c4-2e2d5b-dce8ab25-2e2d5b
18:07:20.906 SIP.STACK MSG Cseq: 3 REFER
;transport=tcp;x-sipX-nonat>
18:07:20.906 SIP.STACK MSG Referred-By: <
18:07:20.906 SIP.STACK MSG Refer-To: <
18:07:20.907 SIP.STACK MSG Date: Wed, 12 Dec 2012 02:07:20 GMT
18:07:20.907 SIP.STACK MSG Max-Forwards: 19
18:07:20.907 SIP.STACK MSG User-Agent: sipXecs/4.4.0
sipXecs/park (Linux)
18:07:20.907 SIP.STACK MSG Accept-Language: en
18:07:20.907 SIP.STACK MSG Allow: INVITE, ACK, CANCEL, BYE,
REFER, OPTIONS, NOTIFY, SUBSCRIBE
18:07:20.907 SIP.STACK MSG Supported: replaces
Refer-To: <
The call-id is not seen anywhere else in this debug meaning, that
portion of the call is not on the ADTRAN. The ADTRAN accepts the Refer to
it is up to the other device to tear that call down.
Regards,
Geoff
-Bryan Anderson

You need to install ngrep and do an ngrep -Wbyline port 5060 to trace
sip messaging

Post by Bryan Anderson
So I pulled some tests and some traces, and have also opened a ticket
with Adtran. Using a Dialog Count I identified the following callid's to
be in reference to one call.
I called into the system with my cell to an alias (1811) on the
extension(5063). I was parked on x6000. Extension 1802 retrieved the call
and then we ended. (4=adtran 5=SipXecs, 181=x5603, 147=x1802)
61 INVITE 2012-12-07T20:05:51
1811(5063) -> 6000
30 INVITE 2012-12-07T20:06:21
30 INVITE 2012-12-07T20:06:27
33 INVITE 2012-12-07T20:06:28
30 INVITE 2012-12-07T20:06:51
29 INVITE 2012-12-07T20:06:52
retrieving the call) 4311 -> 1802
Where does the BLF for the call park get so it doesn't release? That
is what I am looking for. I am sorry I just don't know the SIP protocol
well enough to find it on my own. I have seen this with Polycom firmwares
3.2.4, 3.2.7 and yes 3.3.0 and 4.0.3(this trace). I have a debug off the
adtran to send to them, but they asked me were it is failing and I just
don't know for sure myself.
-Bryan Anderson
Thanks for the reply and I will defiantly test it. We use a T1 for
service into the Adtran and the Adtran is in SipXecs as an unmanaged
gateway.
-Bryan Anderson
On Fri, Dec 7, 2012 at 11:07 AM, Ali Ardestani <
This is how we implemented call park with polycom and it works (it is
a workaround though)
1. Extension 700 forwards to 701, 702, 703 and 703
2. added the below to the custom config of the phones (this is done
so that the key does not timeout after 1 minute and call the park orbit
directly
<call
call.offeringTimeOut="3600"
call.directedCallPickupMethod="legacy"
call.parkedCallRetrieveMethod="legacy"
3. subscribe to the presence of 700 on user speed dials
4. Make sure you use the bridge, we had problems with the call
unparking when we did not use the bridge for incoming calls from trunk
provider
*5. Our firewal does ALG, so we had to uncheck "Use public address
for call setup" under Devices=>Gateways(choose the gw)=>ITSP Account, This
fixed our problem with the calls unparking, maybe your firewall is also
doing some form of ALG*
So I noticed some talk in a previous email "Call forward fails to
external number" about the Adtran 900 series. I have a couple of comments
and questions.
We have a TA908e 2nd gen running AOS A5.02.00.E. We currently have
not noticed any issue with having an external caller forwarded to
and external number. cell => user for 30sec => external number.
What we have had issues with is presence monitoring of call
parking. We have a Polycom Soundpoint IP 650 with a sing side car
that monitors park lines 6000 - 6003. We can park calls no problem,
and so far have not had trouble retrieving calls. Our problem is that
once the call gets retrieved from the call park the BLF never stops
blinking. I have to restart the Park/Presence servers.
This is with SipXecs 4.4.0.
Thoughts and comments would be appreciated.
-Bryan Anderson
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/
--
--
Ali S Ardestani
Telephony Systems Engineer
Private National Mortgage Acceptance Company (PennyMac)
6101 Condor Drive
Moorpark, CA 93021

_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

--
Josh Patten
eZuce
Solutions Architect
O.978-296-1005 X2050
M.979-574-5699
http://www.ezuce.com

Bryan Anderson

2012-12-12 23:36:47 UTC

Permalink

Ok thanks. I just sent if off. I did just remember, they mentioned if the
adtran is set for "Network" transfer vs "Local" it wouldn't work.

"For example, the ADTRAN will not send an INVITE in response to a REFER if
the transfer-mode is network"

I tried setting the transfer mode to "Local" and when I park a call
"transfer+ext" it kick the user into the voice mail of the person
transferring them.

Does that help with or change anything at all? Clearly its not right.

-Bryan Anderson

Post by Josh Patten
Try sending them my response to the mailing list and see where that gets
you. If they balk at it, then I'll see how I can explain it better to them.

;party=calling;screen=yes;privacy=off

So as I said before I am not well versed in the SIP protocol but this
was Adtrans response.
Thanks Bryan,
I do not believe this to be an ADTRAN issue. The call leg that is
being replaced only exists on that PBX. Check out the Refer message sent
Rx: UDP src=10.0.31.5:5060 dst=10.0.31.4:5060
18:07:20.905 SIP.STACK MSG REFER sip:10.0.31.4:5060;transport=
UDP SIP/2.0

;tag=NkynMZ

<sip:10.0.31.4>;tag=3bd6630-7f000001-13c4-2e2d5b-dce8ab25-2e2d5b
18:07:20.906 SIP.STACK MSG Cseq: 3 REFER
;transport=tcp;x-sipX-nonat>
18:07:20.906 SIP.STACK MSG Referred-By: <
18:07:20.906 SIP.STACK MSG Refer-To: <
18:07:20.907 SIP.STACK MSG Date: Wed, 12 Dec 2012 02:07:20 GMT
18:07:20.907 SIP.STACK MSG Max-Forwards: 19
18:07:20.907 SIP.STACK MSG User-Agent: sipXecs/4.4.0
sipXecs/park (Linux)
18:07:20.907 SIP.STACK MSG Accept-Language: en
18:07:20.907 SIP.STACK MSG Allow: INVITE, ACK, CANCEL, BYE,
REFER, OPTIONS, NOTIFY, SUBSCRIBE
18:07:20.907 SIP.STACK MSG Supported: replaces
Refer-To: <
The call-id is not seen anywhere else in this debug meaning, that
portion of the call is not on the ADTRAN. The ADTRAN accepts the Refer to
it is up to the other device to tear that call down.
Regards,
Geoff
-Bryan Anderson
On Sat, Dec 8, 2012 at 12:19 AM, Ali Ardestani <

You need to install ngrep and do an ngrep -Wbyline port 5060 to
trace sip messaging

Post by Bryan Anderson
So I pulled some tests and some traces, and have also opened a
ticket with Adtran. Using a Dialog Count I identified the following
callid's to be in reference to one call.
I called into the system with my cell to an alias (1811) on the
extension(5063). I was parked on x6000. Extension 1802 retrieved the call
and then we ended. (4=adtran 5=SipXecs, 181=x5603, 147=x1802)
61 INVITE 2012-12-07T20:05:51
1811(5063) -> 6000
30 INVITE 2012-12-07T20:06:21
30 INVITE 2012-12-07T20:06:27
33 INVITE 2012-12-07T20:06:28
30 INVITE 2012-12-07T20:06:51
29 INVITE 2012-12-07T20:06:52
1802 retrieving the call) 4311 -> 1802
Where does the BLF for the call park get so it doesn't release?
That is what I am looking for. I am sorry I just don't know the SIP
protocol well enough to find it on my own. I have seen this with Polycom
firmwares 3.2.4, 3.2.7 and yes 3.3.0 and 4.0.3(this trace). I have a debug
off the adtran to send to them, but they asked me were it is failing and I
just don't know for sure myself.
-Bryan Anderson
Thanks for the reply and I will defiantly test it. We use a T1 for
service into the Adtran and the Adtran is in SipXecs as an unmanaged
gateway.
-Bryan Anderson
On Fri, Dec 7, 2012 at 11:07 AM, Ali Ardestani <
This is how we implemented call park with polycom and it works (it
is a workaround though)
1. Extension 700 forwards to 701, 702, 703 and 703
2. added the below to the custom config of the phones (this is done
so that the key does not timeout after 1 minute and call the park orbit
directly
<call
call.offeringTimeOut="3600"
call.directedCallPickupMethod="legacy"
call.parkedCallRetrieveMethod="legacy"
3. subscribe to the presence of 700 on user speed dials
4. Make sure you use the bridge, we had problems with the call
unparking when we did not use the bridge for incoming calls from trunk
provider
*5. Our firewal does ALG, so we had to uncheck "Use public address
for call setup" under Devices=>Gateways(choose the gw)=>ITSP Account, This
fixed our problem with the calls unparking, maybe your firewall is also
doing some form of ALG*
So I noticed some talk in a previous email "Call forward fails to
external number" about the Adtran 900 series. I have a couple of comments
and questions.
We have a TA908e 2nd gen running AOS A5.02.00.E. We currently have
not noticed any issue with having an external caller forwarded to
and external number. cell => user for 30sec => external number.
What we have had issues with is presence monitoring of call
parking. We have a Polycom Soundpoint IP 650 with a sing side car
that monitors park lines 6000 - 6003. We can park calls no problem,
and so far have not had trouble retrieving calls. Our problem is that
once the call gets retrieved from the call park the BLF never stops
blinking. I have to restart the Park/Presence servers.
This is with SipXecs 4.4.0.
Thoughts and comments would be appreciated.
-Bryan Anderson
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/
--
--
Ali S Ardestani
Telephony Systems Engineer
Private National Mortgage Acceptance Company (PennyMac)
6101 Condor Drive
Moorpark, CA 93021

_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

--
Josh Patten
eZuce
Solutions Architect
O.978-296-1005 X2050
M.979-574-5699
http://www.ezuce.com

Bryan Anderson

2012-12-13 16:24:38 UTC

Permalink

Here was their reply:

"what specifically do you consider to be a problem in the SIP messaging?"

-Bryan Anderson

Post by Bryan Anderson
Ok thanks. I just sent if off. I did just remember, they mentioned if the
adtran is set for "Network" transfer vs "Local" it wouldn't work.
"For example, the ADTRAN will not send an INVITE in response to a REFER if
the transfer-mode is network"
I tried setting the transfer mode to "Local" and when I park a call
"transfer+ext" it kick the user into the voice mail of the person
transferring them.
Does that help with or change anything at all? Clearly its not right.
-Bryan Anderson

Post by Josh Patten
Try sending them my response to the mailing list and see where that gets
you. If they balk at it, then I'll see how I can explain it better to them.

Post by Josh Patten
It looks like Adtran and Digium are screaming the same thing. I'm
According to http://tools.ietf.org/html/rfc5589#page-26 (see the
refer-to on page 27) this is a valid transfer scenario. I have attached a
valid capture using FreeSWITCH as a gateway, and when the particular REFER
that is giving the Adtran GW problems comes up, it simply performs
sip.corp.ezuce.com SIP/2.0
Call-Id: 4d339693-a499-1230-729f-fad9dc40d221
Cseq: 3 REFER
REPLACES=a0511239-ab6decb2-99d54f8f%40172.16.1.51%3Bto-tag%3DCA50B7BD-573B246%3Bfrom-tag%3DLkTYH8&REQUIRE=replaces&X-sipX-Authidentity=%3Csip%3A%7E%7Eid%7Epark%
40sip.corp.ezuce.com
%3Bsignature%3D509C36D7%253A%253Ad1b624445c9e26173fe0de17f291d62d%3E&REFERENCES=4d339693-a499-1230-729f-fad9dc40d221%3Brel%3Drefer
*>
Date: Thu, 08 Nov 2012 22:48:55 GMT
Max-Forwards: 19
User-Agent: sipXecs/4.6.0 sipXecs/park (Linux)
Accept-Language: en
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE
Supported: replaces
Proxy-Authorization: Digest username="~~id~park", realm="
sip.corp.ezuce.com",
nonce="5c81f6a19cf6bd3bcaefdfe726e2db2e509c36d7",
sip.corp.ezuce.com", response="a8fdc3b3eeb0f5e52ef91342aba9df3f",
cnonce="jbJLTS", qop=auth, nc=00000001
Via: SIP/2.0/UDP
172.16.1.5;branch=z9hG4bK-XX-0b96Qj3NNqiD6usxS_3GIL_emg
Via: SIP/2.0/TCP 172.16.1.5:5120
;branch=z9hG4bK-XX-003aW8u6STjzakMVEqA5D65UPg;id=18008-29
Content-Length: 0
SIP/2.0 202 Accepted
Via: SIP/2.0/UDP
172.16.1.5;branch=z9hG4bK-XX-0b96Qj3NNqiD6usxS_3GIL_emg
Via: SIP/2.0/TCP 172.16.1.5:5120
;branch=z9hG4bK-XX-003aW8u6STjzakMVEqA5D65UPg;id=18008-29
Call-ID: 4d339693-a499-1230-729f-fad9dc40d221
CSeq: 3 REFER
sip.corp.ezuce.com>
Expires: 60
User-Agent: FreeSWITCH-mod_sofia/1.2.3
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE,
REGISTER, REFER, NOTIFY
Supported: timer, precondition, path, replaces
Allow-Events: talk, hold, conference, refer
Content-Length: 0
Via: SIP/2.0/UDP 172.16.1.90:5080;rport;branch=z9hG4bK2pQyFrXy5e8mN
Max-Forwards: 70
Call-ID: 50251028-a499-1230-729f-fad9dc40d221
CSeq: 35871402 INVITE
User-Agent: FreeSWITCH-mod_sofia/1.2.3
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE,
REGISTER, REFER, NOTIFY
*Require: replaces*
Supported: timer, precondition, path, replaces
Allow-Events: talk, hold, conference, refer
;to-tag=CA50B7BD-573B246;from-tag=LkTYH8*
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 255
X-FS-Support: update_display,send_info
;signature=509C36D7%3A%3Ad1b624445c9e26173fe0de17f291d62d>
REFERENCES: 4d339693-a499-1230-729f-fad9dc40d221;rel=refer

;party=calling;screen=yes;privacy=off

So as I said before I am not well versed in the SIP protocol but this
was Adtrans response.
Thanks Bryan,
I do not believe this to be an ADTRAN issue. The call leg that is
being replaced only exists on that PBX. Check out the Refer message sent
Rx: UDP src=10.0.31.5:5060 dst=10.0.31.4:5060
18:07:20.905 SIP.STACK MSG REFER sip:10.0.31.4:5060
;transport=
UDP SIP/2.0

;tag=NkynMZ

<sip:10.0.31.4>;tag=3bd6630-7f000001-13c4-2e2d5b-dce8ab25-2e2d5b
18:07:20.906 SIP.STACK MSG Cseq: 3 REFER
;transport=tcp;x-sipX-nonat>
18:07:20.906 SIP.STACK MSG Referred-By: <
18:07:20.906 SIP.STACK MSG Refer-To: <
18:07:20.907 SIP.STACK MSG Date: Wed, 12 Dec 2012 02:07:20 GMT
18:07:20.907 SIP.STACK MSG Max-Forwards: 19
18:07:20.907 SIP.STACK MSG User-Agent: sipXecs/4.4.0
sipXecs/park (Linux)
18:07:20.907 SIP.STACK MSG Accept-Language: en
18:07:20.907 SIP.STACK MSG Allow: INVITE, ACK, CANCEL, BYE,
REFER, OPTIONS, NOTIFY, SUBSCRIBE
18:07:20.907 SIP.STACK MSG Supported: replaces
Refer-To: <
The call-id is not seen anywhere else in this debug meaning, that
portion of the call is not on the ADTRAN. The ADTRAN accepts the Refer to
it is up to the other device to tear that call down.
Regards,
Geoff
-Bryan Anderson
On Sat, Dec 8, 2012 at 12:19 AM, Ali Ardestani <

You need to install ngrep and do an ngrep -Wbyline port 5060 to
trace sip messaging

Post by Bryan Anderson
So I pulled some tests and some traces, and have also opened a
ticket with Adtran. Using a Dialog Count I identified the following
callid's to be in reference to one call.
I called into the system with my cell to an alias (1811) on the
extension(5063). I was parked on x6000. Extension 1802 retrieved the call
and then we ended. (4=adtran 5=SipXecs, 181=x5603, 147=x1802)
61 INVITE 2012-12-07T20:05:51
1811(5063) -> 6000
30 INVITE 2012-12-07T20:06:21
30 INVITE 2012-12-07T20:06:27
33 INVITE 2012-12-07T20:06:28
30 INVITE 2012-12-07T20:06:51
29 INVITE 2012-12-07T20:06:52
1802 retrieving the call) 4311 -> 1802
Where does the BLF for the call park get so it doesn't release?
That is what I am looking for. I am sorry I just don't know the SIP
protocol well enough to find it on my own. I have seen this with Polycom
firmwares 3.2.4, 3.2.7 and yes 3.3.0 and 4.0.3(this trace). I have a debug
off the adtran to send to them, but they asked me were it is failing and I
just don't know for sure myself.
-Bryan Anderson
On Fri, Dec 7, 2012 at 11:16 AM, Bryan Anderson <
Thanks for the reply and I will defiantly test it. We use a T1 for
service into the Adtran and the Adtran is in SipXecs as an unmanaged
gateway.
-Bryan Anderson
On Fri, Dec 7, 2012 at 11:07 AM, Ali Ardestani <
This is how we implemented call park with polycom and it works (it
is a workaround though)
1. Extension 700 forwards to 701, 702, 703 and 703
2. added the below to the custom config of the phones (this is done
so that the key does not timeout after 1 minute and call the park orbit
directly
<call
call.offeringTimeOut="3600"
call.directedCallPickupMethod="legacy"
call.parkedCallRetrieveMethod="legacy"
3. subscribe to the presence of 700 on user speed dials
4. Make sure you use the bridge, we had problems with the call
unparking when we did not use the bridge for incoming calls from trunk
provider
*5. Our firewal does ALG, so we had to uncheck "Use public address
for call setup" under Devices=>Gateways(choose the gw)=>ITSP Account, This
fixed our problem with the calls unparking, maybe your firewall is also
doing some form of ALG*
On Fri, Dec 7, 2012 at 10:06 AM, Bryan Anderson <
So I noticed some talk in a previous email "Call forward fails to
external number" about the Adtran 900 series. I have a couple of comments
and questions.
We have a TA908e 2nd gen running AOS A5.02.00.E. We currently
have not noticed any issue with having an external caller forwarded
to and external number. cell => user for 30sec => external number.
What we have had issues with is presence monitoring of call
parking. We have a Polycom Soundpoint IP 650 with a sing side
car that monitors park lines 6000 - 6003. We can park calls no problem,
and so far have not had trouble retrieving calls. Our problem is that
once the call gets retrieved from the call park the BLF never
stops blinking. I have to restart the Park/Presence servers.
This is with SipXecs 4.4.0.
Thoughts and comments would be appreciated.
-Bryan Anderson
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/
--
--
Ali S Ardestani
Telephony Systems Engineer
Private National Mortgage Acceptance Company (PennyMac)
6101 Condor Drive
Moorpark, CA 93021

_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4
Ask about our Internet Fax services!
~~~~~~~~~~~~~~~~~~
Using or developing for sipXecs from SIPFoundry? Ask me about
sipX-CoLab 2013!
<http://sipxcolab2013.eventbrite.com/?discount=tony2013>
Telephone: 434.984.8426
Helpdesk Customers: http://myhelp.myitdepartment.**net<http://myhelp.myitdepartment.net>
Blog: http://blog.myitdepartment.net
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

--
Josh Patten
eZuce
Solutions Architect
O.978-296-1005 X2050
M.979-574-5699
http://www.ezuce.com

Josh Patten

2012-12-13 21:59:31 UTC

Permalink

Did I not point it out well enough?

I posted a good SIP flow that you forwarded on to them, no?

I highlighted exactly what was supposed to happen. Their SIP stack is
supposed to take the parameters in the Refer to header and build the INVITE
from them. It really is that simple. Look at the signal example I gave you,
it shows just that.

Adtran is instead trying to compare the replaces value to their internal
call database. This is where they're wrong. The replaces points to a dialog
that is on another device entirely. So instead of trying to find the dialog
that is on another device entirely, in their internal call database, they
simply just need to build the invite with the parameters given in the
refer-to and send it on it's way.

Post by Bryan Anderson
"what specifically do you consider to be a problem in the SIP messaging?"
-Bryan Anderson

Post by Bryan Anderson
Ok thanks. I just sent if off. I did just remember, they mentioned if
the adtran is set for "Network" transfer vs "Local" it wouldn't work.
"For example, the ADTRAN will not send an INVITE in response to a REFER
if the transfer-mode is network"
I tried setting the transfer mode to "Local" and when I park a call
"transfer+ext" it kick the user into the voice mail of the person
transferring them.
Does that help with or change anything at all? Clearly its not right.
-Bryan Anderson

Post by Josh Patten
Try sending them my response to the mailing list and see where that gets
you. If they balk at it, then I'll see how I can explain it better to them.

Post by Josh Patten
;tag=Se415mQNX7D7D

Call-ID: 4d339693-a499-1230-729f-fad9dc40d221
CSeq: 3 REFER
;transport=udp;gw=sip.corp.ezuce.com>
Expires: 60
User-Agent: FreeSWITCH-mod_sofia/1.2.3
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE,
REGISTER, REFER, NOTIFY
Supported: timer, precondition, path, replaces
Allow-Events: talk, hold, conference, refer
Content-Length: 0
Via: SIP/2.0/UDP 172.16.1.90:5080;rport;branch=z9hG4bK2pQyFrXy5e8mN
Max-Forwards: 70
Call-ID: 50251028-a499-1230-729f-fad9dc40d221
CSeq: 35871402 INVITE
User-Agent: FreeSWITCH-mod_sofia/1.2.3
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE,
REGISTER, REFER, NOTIFY
*Require: replaces*
Supported: timer, precondition, path, replaces
Allow-Events: talk, hold, conference, refer
;to-tag=CA50B7BD-573B246;from-tag=LkTYH8*
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 255
X-FS-Support: update_display,send_info
;signature=509C36D7%3A%3Ad1b624445c9e26173fe0de17f291d62d>
REFERENCES: 4d339693-a499-1230-729f-fad9dc40d221;rel=refer

Post by Josh Patten
;party=calling;screen=yes;privacy=off

Obviously the Adtran will not have knowledge of it, it's a call
dialog on a completely different SIP client. Refer-To does not use existing
2.4.3 Accessing the Referred-to Resource
The resource identified by the Refer-To URI is contacted using the
normal mechanisms for that URI type. For example, if the URI is a
SIP URI indicating INVITE (using a method=INVITE URI parameter for
example), the UA would issue a new INVITE using all of the normal
rules for sending an INVITE defined in [1].

Post by Josh Patten
So as I said before I am not well versed in the SIP protocol but
this was Adtrans response.
Thanks Bryan,
I do not believe this to be an ADTRAN issue. The call leg that is
being replaced only exists on that PBX. Check out the Refer message sent
Rx: UDP src=10.0.31.5:5060 dst=10.0.31.4:5060
18:07:20.905 SIP.STACK MSG REFER sip:10.0.31.4:5060
;transport=
UDP SIP/2.0

;tag=NkynMZ

<sip:10.0.31.4>;tag=3bd6630-7f000001-13c4-2e2d5b-dce8ab25-2e2d5b
18:07:20.906 SIP.STACK MSG Cseq: 3 REFER
;transport=tcp;x-sipX-nonat>
18:07:20.906 SIP.STACK MSG Referred-By: <
18:07:20.906 SIP.STACK MSG Refer-To: <
18:07:20.907 SIP.STACK MSG Date: Wed, 12 Dec 2012 02:07:20 GMT
18:07:20.907 SIP.STACK MSG Max-Forwards: 19
18:07:20.907 SIP.STACK MSG User-Agent: sipXecs/4.4.0
sipXecs/park (Linux)
18:07:20.907 SIP.STACK MSG Accept-Language: en
18:07:20.907 SIP.STACK MSG Allow: INVITE, ACK, CANCEL, BYE,
REFER, OPTIONS, NOTIFY, SUBSCRIBE
18:07:20.907 SIP.STACK MSG Supported: replaces
Refer-To: <
The call-id is not seen anywhere else in this debug meaning, that
portion of the call is not on the ADTRAN. The ADTRAN accepts the Refer to
it is up to the other device to tear that call down.
Regards,
Geoff
-Bryan Anderson
On Sat, Dec 8, 2012 at 12:19 AM, Ali Ardestani <

You need to install ngrep and do an ngrep -Wbyline port 5060 to
trace sip messaging

Post by Bryan Anderson
So I pulled some tests and some traces, and have also opened a
ticket with Adtran. Using a Dialog Count I identified the following
callid's to be in reference to one call.
I called into the system with my cell to an alias (1811) on the
extension(5063). I was parked on x6000. Extension 1802 retrieved the call
and then we ended. (4=adtran 5=SipXecs, 181=x5603, 147=x1802)
61 INVITE 2012-12-07T20:05:51
1811(5063) -> 6000
30 INVITE 2012-12-07T20:06:21
30 INVITE 2012-12-07T20:06:27
33 INVITE 2012-12-07T20:06:28
30 INVITE 2012-12-07T20:06:51
29 INVITE 2012-12-07T20:06:52
1802 retrieving the call) 4311 -> 1802
Where does the BLF for the call park get so it doesn't release?
That is what I am looking for. I am sorry I just don't know the SIP
protocol well enough to find it on my own. I have seen this with Polycom
firmwares 3.2.4, 3.2.7 and yes 3.3.0 and 4.0.3(this trace). I have a debug
off the adtran to send to them, but they asked me were it is failing and I
just don't know for sure myself.
-Bryan Anderson
On Fri, Dec 7, 2012 at 11:16 AM, Bryan Anderson <
Thanks for the reply and I will defiantly test it. We use a T1
for service into the Adtran and the Adtran is in SipXecs as an unmanaged
gateway.
-Bryan Anderson
On Fri, Dec 7, 2012 at 11:07 AM, Ali Ardestani <
This is how we implemented call park with polycom and it works (it
is a workaround though)
1. Extension 700 forwards to 701, 702, 703 and 703
2. added the below to the custom config of the phones (this is
done so that the key does not timeout after 1 minute and call the park
orbit directly
<call
call.offeringTimeOut="3600"
call.directedCallPickupMethod="legacy"
call.parkedCallRetrieveMethod="legacy"
3. subscribe to the presence of 700 on user speed dials
4. Make sure you use the bridge, we had problems with the call
unparking when we did not use the bridge for incoming calls from trunk
provider
*5. Our firewal does ALG, so we had to uncheck "Use public
address for call setup" under Devices=>Gateways(choose the gw)=>ITSP
Account, This fixed our problem with the calls unparking, maybe your
firewall is also doing some form of ALG*
On Fri, Dec 7, 2012 at 10:06 AM, Bryan Anderson <
So I noticed some talk in a previous email "Call forward fails to
external number" about the Adtran 900 series. I have a couple of comments
and questions.
We have a TA908e 2nd gen running AOS A5.02.00.E. We currently
have not noticed any issue with having an external caller forwarded
to and external number. cell => user for 30sec => external number.
What we have had issues with is presence monitoring of call
parking. We have a Polycom Soundpoint IP 650 with a sing side
car that monitors park lines 6000 - 6003. We can park calls no problem,
and so far have not had trouble retrieving calls. Our problem is
that once the call gets retrieved from the call park the BLF
never stops blinking. I have to restart the Park/Presence
servers.
This is with SipXecs 4.4.0.
Thoughts and comments would be appreciated.
-Bryan Anderson
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/
--
--
Ali S Ardestani
Telephony Systems Engineer
Private National Mortgage Acceptance Company (PennyMac)
6101 Condor Drive
Moorpark, CA 93021

_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: 434.984.8430
Fax: 434.465.6833
~~~~~~~~~~~~~~~~~~
http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4
Ask about our Internet Fax services!
~~~~~~~~~~~~~~~~~~
Using or developing for sipXecs from SIPFoundry? Ask me about
sipX-CoLab 2013!
<http://sipxcolab2013.eventbrite.com/?discount=tony2013>
Telephone: 434.984.8426
Helpdesk Customers: http://myhelp.myitdepartment.**net<http://myhelp.myitdepartment.net>
Blog: http://blog.myitdepartment.net
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

--
Josh Patten
eZuce
Solutions Architect
O.978-296-1005 X2050
M.979-574-5699
http://www.ezuce.com

_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

--
Josh Patten
eZuce
Solutions Architect
O.978-296-1005 X2050
M.979-574-5699
http://www.ezuce.com