Advertisement

08.15.2008 at 06:39AM PDT, ID: 23651200
[x]
Attachment Details
[x]
The Solution Rating System

With so many solutions, how can you tell which solutions are most likely to help you and which ones are not? To provide you with a tool to use, we rate our solutions based on various elements that most accurately determine if a solution is a quality solution. To explain what factors affect the solution rating, here are the elements we take into consideration when formulating our solution rating.

  • The Grade of the Solution
  • The Zone Rank of the Expert Providing the Solution
  • The Number of Author and Expert Comments
  • The Number of Experts Contributing
  • The Feedback of the Community

Your Input Matters
Because of the way the system is set up, the most important variable in this equation is you. As a member of Experts Exchange, you are able to cast your vote on the quality of the solutions in regard to how complete, accurate, helpful and easy to understand each solution is. When you provide your feedback, each rating is adjusted accordingly. So, if you see a solution that has a poor rating that you think is a good solution, let us know by rating it. As you do, the rating will be adjusted and will become more accurate for other members of our site.

If you have any suggestions that you would like to make for our rating system, please ask a question in the Suggestions Zone of Community Support.

Thank you!
7.7

Extesion check after a SIP REFER?

Asked by eigbar in Voice Over IP, Networking Protocols, Asterisk Open Source Telephony

Tags: , , ,

Hi all,

My question is related to attended transfers using Asterisk and Polycom IP Phones and EyeBeam Softphone as user agents.
 
As I could understand, looks like after each REFER, Asterisk checks whether the transferor can reach the target extension via its default context. See bellow an example:
 
REFER sip:235@200.XXX.XXX.35 SIP/2.0
Via: SIP/2.0/UDP 200.YYY.YYY.87;branch=z9hG4bK76bec12d2FD069B6
From: <sip:10.ext101@200.YYY.YYY.87>;tag=F810E8F1-6A9966A
To: "EXT 1" <sip:235@200.XXX.XXX.35>;tag=as638c860f
CSeq: 2 REFER
Call-ID: 376487393bb717380578a58b3ad9707c@200.XXX.XXX.35
Contact: <sip:10.ext101@200.YYY.YYY.87>
User-Agent: PolycomSoundPointIP-SPIP_650-UA/3.0.2.0972
Refer-To: <sip:2@servername.domain.com.br;user=phone?Replaces=fac455c9-735967e2-bf510297%40200.YYY.YYY.87%3Bto-tag%3Das39a366f4%3Bfrom-tag%3D840EBF78-DF8CE1D5>
Referred-By: <sip:10.ext101@servername.domain.com.br>
Max-Forwards: 70
Content-Length: 0
 
<------------->
--- (12 headers 0 lines) ---
Call 376487393bb717380578a58b3ad9707c@200.XXX.XXX.35 376487393bb717380578a58b3ad9707c@200.XXX.XXX.35  got a SIP call transfer from caller: (REFER)!
SIP transfer to extension 2@10.profile_controller 2@10.profile_controller by 10.ext101@servername.domain.com.br
 

In the above example, where the transfer was made by a Polycom IP Phone, my assuption seems to be correct, since 10.profile_controller is the default context for extension 10.ext101. However, when I do something similar using EyeBeam, I get the following:

REFER sip:235@200.XXX.XXX.35 SIP/2.0
To: <sip:235@servername.domain.com.br>;tag=as177f9062
From: 10.ext2<sip:10.ext2@servername.domain.com.br>;tag=1474c877
Via: SIP/2.0/UDP 200.YYY.YYY.206:10123;branch=z9hG4bK-d87543-928016851-1--d87543-;rport
Call-ID: 3b6519606a2c7276
CSeq: 4 REFER
Contact: <sip:10.ext2@200.YYY.YYY.206:10123>
Max-Forwards: 70
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
Proxy-Authorization: Digest username="10.ext2",realm="domain",nonce="4dc6929d",uri="sip:235@200.XXX.XXX.35",response="4a827112db90724f2d6428f804051613",algorithm=MD5
User-Agent: eyeBeam release 3007n stamp 17816
Refer-To: "EXT 101"<sip:101@200.XXX.XXX.35?Replaces=6f8c3ea77bffb4665d2b04377e76b1c2%40200.XXX.XXX.35%3Bto-tag%3Das069787dd%3Bfrom-tag%3D707d2653>
Referred-By: 10.ext2<sip:10.ext2@servername.domain.com.br>
Content-Length: 0

<------------->
--- (14 headers 0 lines) ---
Call 3b6519606a2c7276 got a SIP call transfer from caller: (REFER)!
Failed SIP Transfer to non-existing extension 101 in context 10.outgoing_names



In this case, the transfer fails because context 10.outgoing_names is not prepared to handle calls to extension 101. Also, this is not the default context for any of the involved peers.

My question is what defines the context Asterisk uses to check the extensions after a REFER. Also, why Eyebeam's behavior is different from Polycom's?

Thanks in advance!
Start Free Trial
[+][-]08.21.2008 at 02:40PM PDT, ID: 22284573

View this solution now by starting your 30-day free trial. Setting up your free trial is quick, easy, and secure. We will return you to this solution, unlocked, when you're done.

 

About this solution

Zones: Voice Over IP, Networking Protocols, Asterisk Open Source Telephony
Tags: Digium, Asterisk, 1.4.17, Failed SIP Transfer to non-existing extension 101 in context 10.outgoing_names
Sign Up Now!
Solution Provided By: feptias
Participating Experts: 1
Solution Grade: B
 
 
 
Loading Advertisement...
20081112-EE-VQP-44 / EE_QW_2_20070628