[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Issue 196: User-Name Attribute
Right, but it's my understanding (laboriously gained, yet perhaps still
flawed) that the SIP proxy >functionality was expected to deliver the SIP
request to the destination realm; if the user has no >account in that
realm, they are simply out of luck. This would seem to imply that RADIUS
proxies >are unnecessary, at least insofar as inter-realm routing is
That might be correct, but it is still possible for proxies to be deployed
within the destination realm, no?
OK, I give up: how does the Calling-Station-Id help to route RADIUS
Presumably a RADIUS proxy determines that the Calling-Station-Id has been
placed in the User-Name attribute by comparing it to the Calling-Station-Id,
and then routes the request to the RADIUS server in the local realm.
Of course, I'm not clear that RFC 3579 implementations actually do this;
most RADIUS clients always send an EAP-Request/Identity and so they always
have something to put in the User-Name attribute (except if the client
responds with a null EAP-Response/Identity).
This specification seems unique in that the RADIUS client will *never* have
something to put in the User-Name attribute, so this is no longer a corner
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.