[Serusers] 487 hop to hop????
lgfausak at gmail.com
Thu Aug 25 16:58:28 CEST 2005
On Aug 25, 2005, at 9:30 AM, Klaus Darilion wrote:
> Hi Greg!
> Greg Fausak wrote:
>> I've been scouring the RFCs looking for this verbiage.
>> One of our developers here is telling me that is a mistake, that the
>> 487 needs to come from the far end. Do you know where I might
>> find more information about this topic?
> Imagine a forked call. If the call in canceled, ser has to wait for
> the 487 messages from all branches. Only after it received the 487
> from all branches, it will send a 487 to the caller.
Using this logic ser has to wait for the 487 before it sends it to the
caller. What I'm seeing is the 487 is sent straight away, right
200. Is this because the call is not forked? If it was forked I'd
see the 487s
come back to the ser proxy before the ser proxy sends it to the caller?
>> It seems to me that the ser proxy is responding to the cancel with
>> a 487. If I had to make it come from the far end can that be
> What would be the difference if it would come end2end? The caller
> will receive a 487 which will match the call-id and from tag (I
> think the to-tag will be the to-tag of the last 487 received from
> called parties).
> Thus, the caller can not distinghuish if it is generated from ser
> or from a caller.
I think that is the crux of the matter.
The to-tag isn't available when the call is INVITEd.
So, the bottom line is a 487 is hop to hop, just like a cancel.
>> accomplished with
>> Thank you for your feedback,
>> On Aug 25, 2005, at 1:47 AM, Klaus Darilion wrote:
>>> That's right! CANCEL and 487 are hob-by-hob, if the
>>> corresponding INVITE was forwarded stateful.
>>> Greg Fausak wrote:
>>>> I've got a call trace that shows an INVITE being CANCELed, the
>>>> CANCEL is hop to hop. I had thought the 487 was generated
>>>> at the other end and came all the way back, but my call
>>>> traces indicate that the 487 is being generated hop to hop as well.
>>>> That's not right, is it?
>>>> Serusers mailing list
>>>> serusers at lists.iptel.org
More information about the sr-users