Cullen Jennings wrote:
I actually don't think that is the case. My recollection, could be very
wrong, what that SER edits outbound, not inbound SDP. That said, if SER
editing my inbound SDP,
it would check the signature before doing so,
and then go and execute my black list that rejected calls at 2 am form
people other than a certain set, then send the call down to me. Once
again, I not getting what is broken in this case.
well both inbound and outbound proxy servers may or may not edit SDP. If
NAT is the driving reasons, inbound proxy can only do so if the caller
appears natted, and outbound proxy can do so if the callee appears natted,
leading all four combinations of inbound/outbound rewriting/leaving.
If one is happy with establishing the secured relationship only between
those two proxies (inbound rewriting *before* signing, outbound rewriting
*after* signing and no rewriting between them), it can work. Not
representing
everyone's favorite scenario, I think this is of importance. The hard
part is the "no rewriting between them" -- that's broken too frequently.
-jiri
On Dec 10, 2008, at 6:20 PM, Dean Willis wrote:
On Dec 10, 2008, at 6:48 PM, Cullen Jennings wrote:
>>
>
> Jiri, I would like to make sure I understand exactly what is broken
> here. So, say some B2BUA that implements 4474, like SER is running
> at iptel.org. And I have an account, say [EMAIL PROTECTED] Now my
> phone is registered and sends an INVITE to SER with the From set to
"[EMAIL PROTECTED]
> ". My understanding is SER edits the SDP then does the 4474
> signature and sends it on.
>
> So in the case you are discussing here, what exactly is broken that
> stops iptel.org from both editing SDP and doing 4474?
>
I'm not Jiȓi, but:
The INVITE hits the SER proxy at the terminating domain, say FWD,
which then rewrites the SDP and sends it on. The originating signature
is now broken. Or the FWD proxy rewrites the signature, and the cert
doesn't match the domain. Broken.
--
Dean
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
