2011/4/27 Kevin P. Fleming :
>> These two usages terminate *independently* of one another. The
>> invite-dialog-usage will probably end with a BYE when the transfer
>> succeeds. But the subscribe-dialog-usage, and hence the dialog, remains
>> until you terminate it, with the appropriate NOTIFY mess
On 04/26/2011 04:30 PM, Paul Kyzivat wrote:
>
>
> On 4/26/2011 1:09 PM, isshed wrote:
>> Thanks Dale for your response. so the other doubt is what will happed to
>> this dialog when the call gets transferred. does it not get destroyed with
>> the BYE? if so what about the rest of the notify?
>
> Yo
On 4/26/2011 1:09 PM, isshed wrote:
> Thanks Dale for your response. so the other doubt is what will happed to
> this dialog when the call gets transferred. does it not get destroyed with
> the BYE? if so what about the rest of the notify?
You should read 5057 on dialog usages - you need to unde
The transfer controller will release the dialog with a BYE.
On Tue, Apr 26, 2011 at 1:09 PM, isshed wrote:
> Thanks Dale for your response. so the other doubt is what will happed to
> this dialog when the call gets transferred. does it not get destroyed with
> the BYE? if so what about the rest
Take a look into the call flow and then you will find out when you have
to drop the dialog after send the REFER.
From: ext isshed [mailto:isshed@gmail.com]
Sent: Tuesday, April 26, 2011 12:58 PM
To: Pavesi, Valdemar (NSN - US/Irving)
Cc: Worley, Dale R (Dale); sip-implementors
Subj
thanks for your response Pavesi..but my question was not about the type of
call transfer. should i rephrase my doubts?
On Tue, Apr 26, 2011 at 10:52 PM, Pavesi, Valdemar (NSN - US/Irving) <
valdemar.pav...@nsn.com> wrote:
> Hello,
>
> There are two type of call transfer.
>
> A) call transfer atte
Hello,
There are two type of call transfer.
A) call transfer attended
http://www.tech-invite.com/Ti-sip-service-05.html
b) call transfer unattended
http://www.tech-invite.com/Ti-sip-service-04.html
Regards!
Valdemar
-Original Message-
From: sip-implementors-boun...@lists.cs.colum
Thanks Dale for your response. so the other doubt is what will happed to
this dialog when the call gets transferred. does it not get destroyed with
the BYE? if so what about the rest of the notify?
I know I am asking the basics but it will improve my understanding.
Thanks.
On Tue, Apr 26, 2011 a
From: Iñaki Baz Castillo [i...@aliax.net]
2011/4/26 Worley, Dale R (Dale) :
> Suppose I forward my phone number to another AOR. After a while, that AOR
> becomes
> invalid due to some circumstance I am unaware of. If a call comes to my
> phone, the forw
2011/4/26 Worley, Dale R (Dale) :
> Suppose I forward my phone number to another AOR. After a while, that AOR
> becomes
> invalid due to some circumstance I am unaware of. If a call comes to my
> phone, the forwarding
> to the other AOR returns 404.
Why would it return 404? what do you mean wi
2011/4/26 Kevin P. Fleming :
> What would be a better response code to return when the user of the
> phone has manually rejected/declined the call? '486 Busy Here' seems a
> bit inappropriate, although I guess it's not terrible.
Options (better than 603 Decline):
- 480 Not Available: Too much a
RFC 3261 suggests "480 Temporarily Unavailable" is ok for "do not disturb".
For me declining manually is no different to declining automatically
Regards
Attila
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.
From: sip-implementors-boun...@lists.cs.columbia.edu
[sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Kevin P. Fleming
[kpflem...@digium.com]
What would be a better response code to return when the user of the
phone has manually rejected/decl
2011/4/26 Kevin P. Fleming :
> PSTN scenarios are "custom/specific" scenarios :-) I'm not aware of
> forking being used in 'PSTN scenarios' at all, really, since I've never
> heard of any PSTN feature that would fork a call. Even the 'call
> forward-no answer' and 'call forward-busy' features are i
On 04/26/2011 10:41 AM, Worley, Dale R (Dale) wrote:
>
> From: Iñaki Baz Castillo [i...@aliax.net]
>
> A cool example is when a proxy calls a user registered in two phones.
> Both phones ring but a person in one of them rejects the call and his
> phone gener
On 04/26/2011 10:34 AM, Iñaki Baz Castillo wrote:
> Dale, I do know how serial forking works. Serial forking makes sense
> when the tryed branch fails due to a real "error"
> (500/503/408/timeout...), but not on a 404. Of course, it could occur
> that in a custom/specific scenario it makes sense t
From: Iñaki Baz Castillo [i...@aliax.net]
A cool example is when a proxy calls a user registered in two phones.
Both phones ring but a person in one of them rejects the call and his
phone generates a 603. The phone stops ringing in the second phone
(which i
From: Iñaki Baz Castillo [i...@aliax.net]
Dale, I do know how serial forking works. Serial forking makes sense
when the tryed branch fails due to a real "error"
(500/503/408/timeout...), but not on a 404. Of course, it could occur
that in a custom/specific
2011/4/26 Worley, Dale R (Dale) :
> What is the reason? I know that in sipXecs, we've effectively removed the
> 6xx responses
> by adjusting the proxy to treat them in the same way as 4xx responses.
> Everything works
> better because of that. It seems to me that 6xx was *fundamentally* a
> m
2011/4/26 Worley, Dale R (Dale) :
>> From: Iñaki Baz Castillo [i...@aliax.net]
>>
>> But, why should a proxy generate a new branch after receiving a 404?
>
> Because that is a ubiquitously-used mechanism in SIP -- if the attempt
> to reach one contact point or destination fails, the call is then
>
Although it is not mentioned in any of the RFCs, the universal way of using
REFER for call transfer is to send the REFER within the dialog that you are
transferring, the dialog that was created by the initial INVITE. "Out of
dialog REFER" is rarely used for call transfer.
It is very uncommon t
Worley, Dale R (Dale) wrote:
> What is the reason?
Ah, if you read my previous emails I confessed in not
being able to remember it. I wish I did. It will
be nice to talk about why we went with a 6xx-class
with others in Quebec City.
> I know that in sipXecs, we've effectively removed the 6xx re
From: Vijay K. Gurbani [v...@bell-labs.com]
SIP has a 6xx-class response for a reason.
What is the reason? I know that in sipXecs, we've effectively removed the 6xx
responses
by adjusting the proxy to treat them i
Worley, Dale R (Dale) wrote:
> Well, yes, if there is no forking, then 6xx doesn't present any
> problems. But forking is a inherent part of SIP, and (at least in the
> 6 years of experience I have building SIP-based PBXs) forking is
> ubiquitous in implementing interesting and useful features.
F
From: Vijay K. Gurbani [v...@bell-labs.com]
In an earlier email [1], I outlined two cases where a globally
authoritative usage appears to make sense, although note that no
forking was involved in these examples.
Wel
> From: Iñaki Baz Castillo [i...@aliax.net]
>
> But, why should a proxy generate a new branch after receiving a 404?
Because that is a ubiquitously-used mechanism in SIP -- if the attempt
to reach one contact point or destination fails, the call is then
routed to another, lower-priority, destinat
It sounds like you may be confusing rfc3261 defined "dialog" with the rfc5057
defined "dialog usage".
RFC 3261 indicates a "dialog is identified by a call identifier, local tag, and
a remote tag". See rfc5057 for details concerning multiple dialog usages
within a dialog.
The following thread
Hello All,
I want to implement call transfer feature on a user agent. As you all know
it can be done in 2 way. 1. sending REFER out of dialog and 2. sending REFER
in dialog. As rfc 3515 says "
A REFER request MAY be placed outside the scope of a dialog created with an
INVITE. "
Also as per RFC 3
28 matches
Mail list logo
