RE: Issue 196: User-Name Attribute

["Bernard Aboba" <bernard_aboba@hotmail.com>]

> 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 
> concerned.

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 
> packets?

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 
condition.



--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>