25 Aug
2005
25 Aug
'05
5:58 p.m.
On Aug 25, 2005, at 9:30 AM, Klaus Darilion wrote:
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.
---greg
Hi Greg!
Greg Fausak wrote:
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
after the
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?
Howdy,
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. 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.
regards
klaus
accomplished with
ser?
Thank you for your feedback,
Regards,
---greg
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.
>
> regards
> klaus
>
> 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?
>> ---greg
>> _______________________________________________
>> Serusers mailing list
>> serusers(a)lists.iptel.org
>> http://lists.iptel.org/mailman/listinfo/serusers
>>
>
>
>